I like the artifact abstraction idea. On Jun 13, 2012 5:32 AM, "Mark Struberg" <strub...@yahoo.de> wrote:
> 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 > >
