felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@gmail.com>
Subject Re: Interesting observation regarding org.osgi.framework.bootdelegation
Date Fri, 04 Jan 2008 15:27:23 GMT
Hi Stuart,

Thanks for your comments. They perfectly match, what I came to thinking
of while writing the mail :-)

Regards
Felix

Am Freitag, den 04.01.2008, 19:51 +0800 schrieb Stuart McCulloch:
> On 04/01/2008, Felix Meschberger <fmeschbe@gmail.com> wrote:
> >
> > Hi all,
> >
> > In Apache Sling [1] we had an issue regarding classloading [2], which we
> > could solve by using the org.osgi.framework.bootdelegation property and
> > sharing a library. Even though the solution with the bootdelegation
> > property works, we noticed an interesting situation (see also [3]):
> >
> > Consider bundle B1 exporting package P1 and Bundle B2 importing Package
> > P1. In addition the bootdelegation property is set to include P1.
> >
> > When B2 is resolved (assuming B1 is active), the Felix framework
> > correctly resolves the import of P1 to the bundle B1. When a class from
> > P1 is accessed (in both B1 and B2), the class is of course loaded
> > correctly from the parent class loader as P1 is listed in the
> > bootdelegation property.
> >
> > The question now is: Is it correct to resolve B2's import of P1 to B1 ?
> > Or should imported packages listed in the bootdelegation property not be
> > resolved to other bundles ?
> 
> 
> Well from the perspective of solving bundle constraints, I think it's valid
> semantically to resolve B2's import of P1 to B1, although in practice the
> framework would delegate class load requests from P1 to the parent
> classloader before using B1's classloader, because of bootdelegation.
> 
> Otherwise you could have a situation where the parent classloader can't
> provide P1, but a bundle could - but because P1 was in the bootdelegation
> property that import wire was never resolved :(
> 
> My explanation would be: If you declare the import, it must be resolved,
> > no matter what. To prevent the resolution, the import must not be
> > declared. But then I assume that packages declared in the bootdelegation
> > property never need to be declared as imports, right ?
> 
> 
> Yes, as long as the parent classloader can supply them :)
> 
> If you do declare them as imports then it's just an additional constraint
> that's not strictly necessary, but it would give you some flexibility in the
> future if you decided to move from bootdelegation (see below)
> 
> Is may assumption correct ?
> >
> > In fact, thinking about this situation while writing it down, I am
> > tempted to not list P1 in the bootdelegation but in the
> > org.osgi.framework.system.packages property. In this case both B1 (which
> > also must import its own exports) and B2 would resolve P1 to the system
> > bundle, which would be better - from an administrative and support
> > perspective. WDYT ?
> 
> 
> it's recommended to always import your exports (BND does this for you)
> 
> I see two main scenarios:
> 
> 1) P1 is in the bootdelegation property and is available from
>     the parent classloader (ie. the containing/boot classloader)
> 
>     B2 then doesn't need to explicitly import P1
> 
> 2) P1 is in the org.osgi.framework.system.packages property
>     and is therefore exported by the framework system bundle
> 
>     B2 needs to explicitly import P1
> 
> imho 2) is better, as the dependency is explicit and you could easily
> switch to providing P1 from a non-system bundle without needing to
> rebuild B2 (and therefore get the true benefits of OSGi)
> 
> but in some legacy situations you may need to use 1) because of
> assumptions about the classloading hierarchy in third-party code...
> 
> HTH
> 
> Thanks for any hints.
> >
> > Regards
> > Felix
> >
> > [1] http://incubator.apache.org/sling/
> > [2]
> > http://www.mail-archive.com/sling-dev@incubator.apache.org/msg01518.html
> > [3]
> > http://www.mail-archive.com/sling-dev@incubator.apache.org/msg01567.html
> >
> >
> 
> 


Mime
View raw message