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
