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
>> >>>
>> >>>
>> >>>
>> >>>
>> >>
>> >>
>> >>
>>
>
