OK, this makes sense. The spring-osgi code is resolving the classloader of
the bundle and passing it to some core Spring code to load the resources. I
will see if I can find a way around that and this should be solved.
Thanks!
Chris
On 12/14/06, Richard S. Hall <[EMAIL PROTECTED]> wrote:
Chris Custine wrote:
> 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?
If you call Bundle.getResources(), then ClassLoader.getResources() is
not called in Felix (and I would assume in Equinox). Thus, you shouldn't
have to worry about it if you are calling Bundle.getResources() unless
it is the system bundle. If, on the other hand, you try to get the class
loader of the bundle and then call ClassLoader.getResources() on it,
then you'd be in trouble.
There is one exception to Bundle.getResources() not calling
ClassLoader.getResources() in Felix (and maybe Equinox)...if you are
loading from a package that is being delegated to the boot class loader,
then Felix will call getClass().getClassLoader().getResources(), which
would then cause you difficulty...
Another good reason to not use boot delegation! :-)
-> richard
>
> 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
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >
>>
>
