commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <>
Subject Re: another new URL() question
Date Wed, 13 Jun 2012 09:31:43 GMT
I grabbed a bit deeper and it's even more f****up.

Some containers don't even add 'file://' to the externalForm() they return in their URLs.
You have to add this yourself when doing new URL().
There is no way to have new URL() working properly in a generic way. We must go Davids route
via an 'Archive' abstraction layer which we could plug-in.


----- Original Message -----
> From: "Honton, Charles" <>
> To: Commons Developers List <>; "" <>;
Mark Struberg <>
> Cc: 
> Sent: Monday, June 11, 2012 6:10 PM
> Subject: Re: another new URL() question
> Mark,
> The only mechanism available to extend URLClassLoader's protocol handling
> in a Sun jvm is to add a URLStreamHandler.  It's a difficult task to
> re-implement the class loading architecture, and I'm sure the application
> server environments don't mess with this basic.  (I'm not so sure about
> the Android vm)
> The URLStreamHandler is used by the URL class to parse the string
> representation into a URL object.  So I'm really surprised by the
> situation where !url.equals(new URL(url.toExternalForm())).
> You mentioned that wsjar:// failed this test.  Does websphere return this
> URL from a ClassLoader.getResource()?  If so, what is the class type of
> that instance? (Probably something written by websphere)
> We could add a URLStreamHandler to handle parsing (and handling stream
> requests for) the wsjar URL.
> Chas
> On 6/11/12 7:23 AM, "Matt Benson" <> wrote:
>> Hi, Mark!  This is why I was confused when we touched on this on
>> IRC--I was thinking that the correct handling of URLs was an
>> orthogonal function to [classscan]'s *use* of those same URLs, for
>> this reason.  I had thought there had been, at one time, an OSS Java
>> project to help manage these URLStreamHandlers, but I haven't had any
>> luck finding it again.  If we never do, this could be a second sandbox
>> component, a new piece for Commons [io], or...?  It could be an
>> interesting setup to have a core management infrastructure, with any
>> number of pluggable modules for different OS/container/et al
>> platforms?
>> Matt
>> On Mon, Jun 11, 2012 at 1:56 AM, Mark Struberg <> 
> wrote:
>>>  Regarding the new URL() problem some of you might have more experience
>>> than I do. I only know the problems on some platforms, and after looking
>>> at the URL class in detail, I really wonder whether that was me doing it
>>> wrong or a platform bug.
>>>  My understanding problem is mainly around the URLStreamHandler. There
>>> is a method where one can set a URLStreamHandlerFactory (once for JVM
>>> lifetime):
>>>  URL#setURLStreamHandlerFactory(URLStreamHandlerFactory fac)
>>>  Thus when a ClassLoader#getResources() returns an URL with 
> "wsjar://"
>>> as protocol and it cannot be used for new URL(), then can I safely
>>> assume this is a problem in the container setup? This happens on Oracles
>>> own WebLogic...
>>>  I have not yet tried the following way:
>>>  String protocol = "wsjar";
>>>  URLStreamHandler getURLStreamHandler(protocol)
>>>  and then use the following URL constructor:
>>>  public URL(URL context, String spec, URLStreamHandler handler)
>>>  Can anyone test if this works? Or does anyone know already?
>>>  We might hack a small JSP page which scans for META-INF/MANIFEST.MF and
>>> reports errors with new URL(). That way we could spread the test onto
>>> various platforms.
>>>  LieGrue,
>>>  strub
>>>  ---------------------------------------------------------------------
>>>  To unsubscribe, e-mail:
>>>  For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message