Re: FileURLConnection

[Nic Ferrier]

Erwin Bolwidt <address@hidden> writes:

> Why don't you use the javax.naming abstractions? I know Tomcat uses it  
> with success. It is very extensible  

Using JNDI is not an option.

The Servlet API forces containers to provide the view of the
container's resource base (where the documents as well as the classes
and jars are stored) through URLs.

The simplest way to do that is through file URLs.

In point of fact, Paperclips currently has a URLStreamHandler for
every context, but this is now broken with 1.3 and it also causes
problems with mutliple hosts.


The servlet spec team (of which I'm a member) are currently
considering the use of JNDI as a replacement for URL described
resource bases.

I suspect that when it does arrive (JNDI) it will not be a complete
replacement but will run alongside the existing system. For at least
a couple of versions.



> and it seems better than changing the API of a standard API
> class... 

I didn't propose that, see the next point.


> you couldn't compile the code (without pre-processing) on
> any other implementation of Java's standard APIs; that doesn't feel
> quite right.

I could compile the code.

What I said I wanted to do was change the FileURLConnection
class. This is an implementation class in package:

   gnu.java.net.protocol.file

It is Classpath's equivalent to Sun's standard file protocol handler.

What I am proposing to do is have Paperclips set the GNU class as the
default handler for the "file" protocol (thus overriding Sun's
default) on platforms where the Classpath handler is not already
available.

Where Classpath's handler is already available it will be picked up
automatically.


The only drawback is that Paperlclips will no longer work without the
class. But since I will deliver the class in the Paperclips CVS I
don't see that as a big issue.


Nic