tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remy Maucherat" <>
Subject Re: setURLStreamHandlerFactory--why?
Date Thu, 19 Apr 2001 00:37:49 GMT
----- Original Message -----
From: "Kyle F. Downey" <>
To: <>
Sent: Wednesday, April 18, 2001 6:25 PM
Subject: setURLStreamHandlerFactory--why?

> I'm working with the latest b4-dev from CVS.
> Is there a reason the StandardLoader establishes a URLStreamHandlerFactory
> (a precious resource, since you can set it only once) just for the "jndi:"
> protocol? If all it's used for is to find the protocol handler, that could
> be done less intrusively by using the built-in package-based mechanism.
> My reason for wanting to change this is that it makes using custom URL
> handlers just about impossible from within a webapp. The package-based
> mechanism fails for webapps because loads URLStreamHandlers
> only from the system classpath--so unless you put it in the very
> lowest-level CLASSPATH (edit or catalina.bat, add along with
> bootstrap.jar) it will not be able to instantiate the handler. Installing
> your own URLStreamHandlerFactory is a drastic solution, but in this case,
> the only (code-level) solution.

Fine, but I don't see what that would really solve, since all your webapps
would have to use the same URLStreamHandler after it is set by one of the
webapps, right ?
If it has to be set somewhere, it's definitely in the container. And you can
also create URLs using URL(URL context, String spec, URLStreamHandler
Of course, that won't work if you want to use JARs (which is why I set the
stream handler factory).

I just think the mechanism provided by the JDK totally sucks.

> I will submit a patch to replace the URLStreamHandlerFactory with the
> naming-pattern based mechanism, if you all consider this a bug rather
> than a feature.

I don't consider that a bug, but if you can have the package-naming
mechanism work nice, then we can use it.


View raw message