Erwin Bolwidt <[EMAIL PROTECTED]> 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 _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
