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