commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <jcar...@carmanconsulting.com>
Subject Re: another new URL() question
Date Wed, 13 Jun 2012 12:10:37 GMT
I like the artifact abstraction idea.
On Jun 13, 2012 5:32 AM, "Mark Struberg" <struberg@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_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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message