Subject: Re: bootdelegation vs.
org.osgi.framework.system.packages.extra



2009/9/9 Matthias Neubert <[email protected]>

> Hello,
>
> I'm currently dealing with options of how to make packages which are known
> to osgi framework /system bundle known to
> the bundles installed in the framework.
>
> Ich found org.osgi.framework.system.packages.extra as a working
> possebility.
>
> but: disadvantage: I cannot use wildcards like com.google.*
>
> another option would be using
> org.osgi.framework.bootdelegation=com.google.*
>
> but: disadvantage: If an Bundle wants to use a package from com.google.* it
> usually uses Import-Package in Manifest.
> If so - this bundle cannot be resolved if I use bootdelegation. I guess it
> would work, it the bundle would just use it without importing it explicitly
>
> This is somehow unpretty. I dont know if this behavior is felix specific or
> if its OSGi standard, but if its felix, I'd like to discuss about if its
> usefull to change this.
>

This is all standard OSGi... the reason bootdelegation can accept a wildcard
is because
it follows a delegation approach. Namely if a request to load a class can't
be satisfied by
the available bundles, and the package matches the wildcard, then it is
delegated to the
classloader that loaded the framework (typically the application
classloader).

Contrast this with the extra system packages property, which is used to
augment the list
of packages exported from the system bundle. The system bundle can't know in
advance
what packages might be required from it, so a wildcard doesn't make sense
here.


> Two things would help here, one of them is enough
>
> 1. Option: org.osgi.framework.system.packages.extra accepts wildcards
>
> 2. option: Package-Imports can be satisfied throug "boot delegation
> exports" made by the system bundle
>

there's also...

3. bootdelegation + optional imports

Import-Package: org.foo.wibble;resolution:=optional

4. bootdelegation + dynamic imports

DynamicImport-Package: org.foo.wibble

but they're also not pretty

both optional and dynamic imports allow you to resolve a bundle even if no
other bundle
exports those packages (but it will wire up the package if another bundle
does export it)

btw, the difference between optional / dynamic is: optional packages are
only checked
during bundle resolution, while dynamic packages are checked on every load
request
until they've been satisfied by another bundle.

so what du you think?
>

the best solution is to be explicit about what you're exposing via the
system bundle
- either using the extra system package property, or by attaching fragments
to the
system bundle to extend its exports (so called framework extension bundles)


http://weblogs.java.net/blog/2009/05/29/use-framework-extension-bundles-glassfish-v3

HTH

I guess Option 1 is better, because the bootdelegation-thing feels somehow
> evil.
>
> regards
> Matthias
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>


--
Cheers, Stuart


Programming list archiving by: Enterprise Git Hosting