Currently Equinox just calls the bundle's ClassLoader.getResources from
Bundle.getResources method. This would cause a problem because the
ClassLoader.getResources method always delegates to boot. As BJ points
out we can work around this by not calling ClassLoader.getResources from
Bundle.getResources method, instead we could just call directly into the
OSGi delegation model. But direct callers of ClassLoader.getResources
would still see the problem even if Equinox worked around the
Bundle.getResources issue.
Tom
"Chris Custine" <[EMAIL PROTECTED]>
12/14/2006 11:19 AM
Please respond to
felix-dev@incubator.apache.org
To
felix-dev@incubator.apache.org
cc
Subject
Re: bundle.getResources behavior
Yes, I agree. This definitely turned out to be a spring-osgi issue all
around, although the ClassLoader.getResources() being final could also
cause
problems as well, but I think that some docs to point this issue out is
probably sufficient.
Tom, when you said that you do not do anything in Equinox to get around
this, I assume that you mean that you work around it by not calling
getResources() at all or at least make sure that this issue won't affect
the
calls?
Thanks to everyone for the help.
Chris
On 12/14/06, Richard S. Hall <[EMAIL PROTECTED]> wrote:
>
> Chris Custine wrote:
> > I did figure out the issue about getResources being final but at this
> > point
> > I am not sure this is the problem yet (it certainly will be
> > eventually). I
> > ran all of this through the debugger and when doing a
> > bundle.getResources,
> > the call is resolving up through a SystemBundleContentLoader which
does
> > this:
> >
> > public Enumeration getResources(String name)
> > {
> > try
> > {
> > return getClass().getClassLoader().getResources(name);
> > }
> > catch (IOException ex)
> > {
> > return null;
> > }
> > }
> >
> > so this getClassLoader() call always resolves to
> > sun.misc.Launcher$AppClassLoader which has the main application
> classpath
> > and returns the wrong resources. This doesn't seem right to me, but I
> > may
> > be missing something.
>
> After looking into and thinking about this a bit more, and from the
> thread on the Spring-OSGi mailing list, it looks like this is not really
> an issue with Felix. I at first didn't realize that the above message
> was specifically talking about the System Bundle implementation, which
> is different than the normal Bundle implementation.
>
> Notice, that the System Bundle above does getClass().getClassLoader(),
> so this is not always going to return sun.misc.Launcher$AppClassLoader,
> rather it will return the class loader that loaded
> SystemBundleContentLoader. So, if the host application creates its own
> class loader to load Felix classes, then it will return that class
> loader instead.
>
> So, unless someone has another suggestion, I assume that this is the
> best way to implement Bundle.getResources() for the System Bundle.
>
> As Chris pointed out on the Spring-OSGi list, I think this issue should
> be resolved for Spring by not searching the System Bundle for its
> handlers...
>
> -> richard
>
> >
> > Chris
> >
> >
> > On 12/14/06, Richard S. Hall <[EMAIL PROTECTED]> wrote:
> >>
> >> Richard S. Hall wrote:
> >> > Yeah, when I was thinking about it, I could think of an "elegant"
> >> > solution. Now you have confirmed that. :-)
> >>
> >> Sorry, that should say, "...I could NOT think..."
> >>
> >> -> richard
> >>
> >> >
> >> > -> richard
> >> >
> >> > Thomas Watson wrote:
> >> >> Currently we do not do anything. I am considering making a
> framework
> >> >> extension bundle fragment that adds a bundle classloader that can
be
> >> >> used on J2SE 1.5. The problem I have is that the core Equinox
> >> >> framework is compiled against the OSGi EE minimum 1.1 library. I
> >> >> could add a bundle classloader implementation to the core
framework
> >> >> that extends the existing bundle classloader and overrides the
> >> >> getResources method. Then at runtime pick the correct
> implementation
> >> >> of the bundle classloader depending on the level of the EE. But
> this
> >> >> would force me to compile the core framework against J2SE 1.5.
> >> >> Something I'm not willing to do at this point. For me it is
> probably
> >> >> better to stick this extra class (compiled against J2SE 1.5) in a
> >> >> framework fragment, then runtime can load that version of the
bundle
> >> >> classloader if it is installed and resolved. I would make that
> >> >> fragment bundle have a required EE of J2SE 1.5 so it could not be
> >> >> installed on an older VM.
> >> >>
> >> >> Tom
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> "Richard S. Hall" <[EMAIL PROTECTED]> 12/14/2006 07:35 AM
> >> >> Please respond to
> >> >> felix-dev@incubator.apache.org
> >> >>
> >> >>
> >> >> To
> >> >> felix-dev@incubator.apache.org
> >> >> cc
> >> >>
> >> >> Subject
> >> >> Re: bundle.getResources behavior
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> Thomas Watson wrote:
> >> >>
> >> >>> This is probably because the ClassLoader.getResources method is
> >> >>> final on
> >> >>
> >> >>
> >> >>> J2SE 1.4 and earlier. In J2SE 1.5 they removed the 'final' from
> >> >>> this method. This makes it impossible to implement a "correct"
> >> >>> bundle classloader on J2SE 1.4 and earlier WRT
> >> >>> ClassLoader.getResources. The implementation of the final
> >> >>> ClassLoader.getResources method always
> >> >> checks
> >> >>> the parent classloader first, there is no way for the OSGi Bundle
> >> >>> class loader to override this behavior. We have the exact same
> >> >>> situation in Equinox.
> >> >>>
> >> >>>
> >> >>
> >> >> Ugly.
> >> >>
> >> >> Tom, so do you have some check in place to do the correct thing
when
> >> >> running on 1.5 as opposed to < 1.5 ? If so, what approach do you
> use?
> >> >>
> >> >> -> richard
> >> >>
> >> >>
> >> >>> Tom
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>> "Chris Custine" <[EMAIL PROTECTED]> 12/14/2006 12:37 AM
> >> >>> Please respond to
> >> >>> felix-dev@incubator.apache.org
> >> >>>
> >> >>>
> >> >>> To
> >> >>> felix-dev@incubator.apache.org
> >> >>> cc
> >> >>>
> >> >>> Subject
> >> >>> bundle.getResources behavior
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>> My understanding of the OSGi spec is that Bundle.getResources()
> >> >>> should only
> >> >>> look in the System classpath if the package name is listed in the
> >> >>> org.osgi.framework.bootdelegation property, is that correct? I
am
> >> >> working
> >> >>
> >> >>> on a problem where Felix is returning a resource from a
> >> non-bundle jar
> >> >>> (Felix is embedded) that is on the main application classpath.
Any
> >> >> ideas?
> >> >>
> >> >>> Thanks,
> >> >>> Chris
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>
> >> >>
> >> >>
> >>
> >
>
