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 <[EMAIL PROTECTED]> 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/[EMAIL PROTECTED]/msg01518.html > > [3] > > http://www.mail-archive.com/[EMAIL PROTECTED]/msg01567.html > > > > > >
