You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Matthias Neubert <su...@onlinehome.de> on 2009/09/08 23:10:30 UTC
bootdelegation vs. org.osgi.framework.system.packages.extra
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.
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
so what du you think?
I guess Option 1 is better, because the bootdelegation-thing feels
somehow evil.
regards
Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: bootdelegation vs. org.osgi.framework.system.packages.extra
Posted by Matthias Neubert <su...@onlinehome.de>.
Hello and thanks!
you made my day!
ciao Matthias
Am 09.09.2009 um 09:55 schrieb Don Brown:
> This is exactly why I wrote the lamely named "package scanner":
> http://code.google.com/p/pkgscanner/
>
> We use this at Atlassian to discover the packages at runtime that
> should be exposed via this property.
>
> Don
>
> On Wed, Sep 9, 2009 at 7:10 AM, Matthias
> Neubert<su...@onlinehome.de> wrote:
>> 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.
>>
>> 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
>>
>> so what du you think?
>>
>> I guess Option 1 is better, because the bootdelegation-thing feels
>> somehow
>> evil.
>>
>> regards
>> Matthias
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: bootdelegation vs. org.osgi.framework.system.packages.extra
Posted by Don Brown <do...@gmail.com>.
This is exactly why I wrote the lamely named "package scanner":
http://code.google.com/p/pkgscanner/
We use this at Atlassian to discover the packages at runtime that
should be exposed via this property.
Don
On Wed, Sep 9, 2009 at 7:10 AM, Matthias Neubert<su...@onlinehome.de> wrote:
> 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.
>
> 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
>
> so what du you think?
>
> I guess Option 1 is better, because the bootdelegation-thing feels somehow
> evil.
>
> regards
> Matthias
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: bootdelegation vs. org.osgi.framework.system.packages.extra
Posted by Matthias Neubert <su...@onlinehome.de>.
Hello,
thank you for this explaining answer. I guess I now see the point. The
solution with the
system bundle fragment has for my scenario nearly the same
disadvantage than packages.extra. In words: I don't
want to name every single public package of my lib, because its quite
big an it may change from time to time.(nearly 6month rythm)
A bundle should be able to use the changes, without having me to
update the config of felix, or in the cleaner case to update
the fragment.
Shure it would be consitent to react an update of the lib with an
update of the fragment, but it is to static for me.
So one good solution for me is the Dynamic Import. As far as I see it
does not have significant disadvantages regarding performance.(right?)
Another way would be (but I did not found a possebility in Java) to
build a method, which analyses the names of available packages
(available for the class in which the method is) to build a string fpr
system.packages.extra property. This "hack" would by a dynamic way of
exporting packages explicitly.
Does someone know if this mechanism exists in Java / Felix ?
regards
Matthias
ps: my background: I embed Felix in an Android Application. felix sees
what this android application can see: the android packages (like UI
Elements..) Now I want to have Bundles which can use these Android
packages, but without naming all android packages in felix config in
the Android Hostapplication.
Am 08.09.2009 um 23:48 schrieb Stuart McCulloch:
> 2009/9/9 Matthias Neubert <su...@onlinehome.de>
>
>> 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: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
>
> --
> Cheers, Stuart
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: bootdelegation vs. org.osgi.framework.system.packages.extra
Posted by Stuart McCulloch <mc...@gmail.com>.
2009/9/9 Matthias Neubert <su...@onlinehome.de>
> 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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers, Stuart