Subject: Re: bootdelegation vs.
2009/9/9 Matthias Neubert <sureal@xxxxxxxxxxxxx>
> 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
> but: disadvantage: I cannot use wildcards like com.google.*
> another option would be using
> 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
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
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
what packages might be required from it, so a wildcard doesn't make sense
> 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
3. bootdelegation + optional imports
4. bootdelegation + dynamic imports
but they're also not pretty
both optional and dynamic imports allow you to resolve a bundle even if no
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
during bundle resolution, while dynamic packages are checked on every load
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
- either using the extra system package property, or by attaching fragments
system bundle to extend its exports (so called framework extension bundles)
I guess Option 1 is better, because the bootdelegation-thing feels somehow
> To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
> For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx