felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stuart McCulloch" <stuart.mccull...@jayway.net>
Subject Re: Interesting observation regarding org.osgi.framework.bootdelegation
Date Fri, 04 Jan 2008 11:51:52 GMT
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
>
>


-- 
Cheers, Stuart

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message