You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Chris Custine <ch...@gmail.com> on 2006/12/14 07:37:16 UTC
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
Re: bundle.getResources behavior
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On second thought, as BJ Hargrave pointed out to me, if this is going
through Bundle.getResources() then we should be able to avoid it...I
will look into it a little bit and see if I can figure anything out.
-> richard
Chris Custine wrote:
> 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
>
Re: bundle.getResources behavior
Posted by Chris Custine <ch...@gmail.com>.
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 <he...@ungoverned.org> 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 <he...@ungoverned.org> 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 <he...@ungoverned.org> 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" <he...@ungoverned.org> 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" <ch...@gmail.com> 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
> >> >> >>>
> >> >> >>>
> >> >> >>>
> >> >> >>>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >>
> >> >
> >>
> >
>
Re: bundle.getResources behavior
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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 <he...@ungoverned.org> 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 <he...@ungoverned.org> 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" <he...@ungoverned.org> 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" <ch...@gmail.com> 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
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >
>>
>
Re: bundle.getResources behavior
Posted by Thomas Watson <tj...@us.ibm.com>.
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" <ch...@gmail.com>
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 <he...@ungoverned.org> 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 <he...@ungoverned.org> 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" <he...@ungoverned.org> 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" <ch...@gmail.com> 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
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>
> >> >>
> >> >>
> >>
> >
>
Re: bundle.getResources behavior
Posted by Chris Custine <ch...@gmail.com>.
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 <he...@ungoverned.org> 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 <he...@ungoverned.org> 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" <he...@ungoverned.org> 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" <ch...@gmail.com> 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
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>
> >> >>
> >> >>
> >>
> >
>
Re: bundle.getResources behavior
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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 <he...@ungoverned.org> 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" <he...@ungoverned.org> 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" <ch...@gmail.com> 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
>> >>>
>> >>>
>> >>>
>> >>>
>> >>
>> >>
>> >>
>>
>
Re: bundle.getResources behavior
Posted by BJ Hargrave <ha...@us.ibm.com>.
See seciont 4.5 of the spec.
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave@us.ibm.com
office: +1 407 849 9117
mobile: +1 386 848 3788
"Chris Custine" <ch...@gmail.com>
12/14/2006 11:18 AM
Please respond to
felix-dev@incubator.apache.org
To
felix-dev@incubator.apache.org
cc
Subject
Re: bundle.getResources behavior
Well, thats easy enough! I looked but couldn't find that. Thanks!
Chris
On 12/14/06, Marcel Offermans <ma...@luminis.nl> wrote:
>
> The system bundle has an ID of 0 (zero). This is defined in the spec.
>
> On Dec 14, 2006, at 16:59 , Chris Custine wrote:
>
> > When you do context.getBundles(), is there any way to distinguish
> > the System
> > bundle from other bundles (not Felix specific, hopefully OSGi spec)?
> > Something like a marker or flag?
>
>
Re: bundle.getResources behavior
Posted by Chris Custine <ch...@gmail.com>.
Well, thats easy enough! I looked but couldn't find that. Thanks!
Chris
On 12/14/06, Marcel Offermans <ma...@luminis.nl> wrote:
>
> The system bundle has an ID of 0 (zero). This is defined in the spec.
>
> On Dec 14, 2006, at 16:59 , Chris Custine wrote:
>
> > When you do context.getBundles(), is there any way to distinguish
> > the System
> > bundle from other bundles (not Felix specific, hopefully OSGi spec)?
> > Something like a marker or flag?
>
>
Re: bundle.getResources behavior
Posted by Marcel Offermans <ma...@luminis.nl>.
The system bundle has an ID of 0 (zero). This is defined in the spec.
On Dec 14, 2006, at 16:59 , Chris Custine wrote:
> When you do context.getBundles(), is there any way to distinguish
> the System
> bundle from other bundles (not Felix specific, hopefully OSGi spec)?
> Something like a marker or flag?
Re: bundle.getResources behavior
Posted by Chris Custine <ch...@gmail.com>.
When you do context.getBundles(), is there any way to distinguish the System
bundle from other bundles (not Felix specific, hopefully OSGi spec)?
Something like a marker or flag?
Chris
On 12/14/06, Chris Custine <ch...@gmail.com> wrote:
>
> At this point I have tracked it back to spring-osgi, so let me continue to
> research it and I will post the results on both lists here shortly.
>
> Chris
>
> On 12/14/06, Richard S. Hall <he...@ungoverned.org> 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.
> >
> > Nope, I agree. With you, I just posted a follow up message. I guess you
> > saved me some investigation time...I will look at this more closely and
> > see what I can come up with.
> >
> > -> richard
> >
> > >
> > > Chris
> > >
> > >
> > > On 12/14/06, Richard S. Hall <he...@ungoverned.org> 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" <he...@ungoverned.org> 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" <ch...@gmail.com> 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
> > >> >>>
> > >> >>>
> > >> >>>
> > >> >>>
> > >> >>
> > >> >>
> > >> >>
> > >>
> > >
> >
>
>
Re: bundle.getResources behavior
Posted by Chris Custine <ch...@gmail.com>.
At this point I have tracked it back to spring-osgi, so let me continue to
research it and I will post the results on both lists here shortly.
Chris
On 12/14/06, Richard S. Hall <he...@ungoverned.org> 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.
>
> Nope, I agree. With you, I just posted a follow up message. I guess you
> saved me some investigation time...I will look at this more closely and
> see what I can come up with.
>
> -> richard
>
> >
> > Chris
> >
> >
> > On 12/14/06, Richard S. Hall <he...@ungoverned.org> 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" <he...@ungoverned.org> 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" <ch...@gmail.com> 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
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>
> >> >>
> >> >>
> >>
> >
>
Re: bundle.getResources behavior
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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.
Nope, I agree. With you, I just posted a follow up message. I guess you
saved me some investigation time...I will look at this more closely and
see what I can come up with.
-> richard
>
> Chris
>
>
> On 12/14/06, Richard S. Hall <he...@ungoverned.org> 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" <he...@ungoverned.org> 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" <ch...@gmail.com> 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
>> >>>
>> >>>
>> >>>
>> >>>
>> >>
>> >>
>> >>
>>
>
Re: bundle.getResources behavior
Posted by Chris Custine <ch...@gmail.com>.
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 <he...@ungoverned.org> 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" <he...@ungoverned.org> 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" <ch...@gmail.com> 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
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
>
Re: bundle.getResources behavior
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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" <he...@ungoverned.org> 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" <ch...@gmail.com> 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
>>>
>>>
>>>
>>>
>>
>>
>>
Re: bundle.getResources behavior
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Yeah, when I was thinking about it, I could think of an "elegant"
solution. Now you have confirmed that. :-)
-> 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" <he...@ungoverned.org>
> 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" <ch...@gmail.com>
>> 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
>>
>>
>>
>>
>
>
>
Re: bundle.getResources behavior
Posted by Thomas Watson <tj...@us.ibm.com>.
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" <he...@ungoverned.org>
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" <ch...@gmail.com>
> 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
>
>
>
Re: bundle.getResources behavior
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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" <ch...@gmail.com>
> 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
>
>
>
Re: bundle.getResources behavior
Posted by Thomas Watson <tj...@us.ibm.com>.
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.
Tom
"Chris Custine" <ch...@gmail.com>
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