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