commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
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.

LieGrue,
strub



----- Original Message -----
> From: "Honton, Charles" <Charles_Honton@intuit.com>
> To: Commons Developers List <dev@commons.apache.org>; "gudnabrsam@gmail.com" <gudnabrsam@gmail.com>;
Mark Struberg <struberg@yahoo.de>
> 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" <gudnabrsam@gmail.com> 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 <struberg@yahoo.de> 
> 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: dev-unsubscribe@commons.apache.org
>>>  For additional commands, e-mail: dev-help@commons.apache.org
>>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message