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_hon...@intuit.com> > To: Commons Developers List <dev@commons.apache.org>; "gudnabr...@gmail.com" > <gudnabr...@gmail.com>; Mark Struberg <strub...@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" <gudnabr...@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 <strub...@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-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
