And if you can do that, you should:
1. Set org.osgi.framework.system.packages.extra to the packages you
want to expose from the class path, which causes the system bundle
to export them.
2. Have all of your bundles explicitly import those packages.
You don't need to set org.osgi.framework.system.packages, since it will
be set to all packages in the underlying Java platform. You only need to
set this value if you want to override. Much of this is explained in:
http://cwiki.apache.org/FELIX/apache-felix-framework-launching-and-embedding.html
In general you should never use boot delegation. The whole point behind
boot delegation is if you want to give your bundles implicit access to
packages on the class path. This means the bundles will not need to
import them and will automatically have access to them. This is bad
because it hides dependencies, makes your bundles not easily reusable,
and ignores versions.
-> richard
On 03/18/2009 06:01 PM, Neil Bartlett wrote:
Dmitry,
You appear to be missing the most obvious solution, which is to turn
each of the third party libraries into its own bundle. And in many
cases you won't have to do this yourself, you can use an already
"bundleized" version of the library from one of the common
repositories such as OBR, SpringSource, Eclipse Orbit, etc.
Regards,
Neil
On Wed, Mar 18, 2009 at 9:47 PM, Dmitry Skavish
<[email protected]> wrote:
Hello,
I am complete novice in OSGi and I am stuck trying to find the best solution to
the following problem (which I think should be fairly typical):
We have a large desktop application which we are trying to break into OSGi
bundles. The application uses quite a few third party libraries. We want to
make those libraries available to every bundle. But it does not seem to be that
easy. I tried several approaches and I am satisfied with none :(
I know about properties: FRAMEWORK_SYSTEMPACKAGES and FRAMEWORK_BOOTDELEGATION. So I set
FRAMEWORK_BOOTDELEGATION to "*" and I DO NOT set FRAMEWORK_SYSTEMPACKAGES to
anything.
What I discovered is that in this case if package which comes from libraries on
a classpath IS present in Import-Package in bundle's manifest then this bundle
won't be resolved (error). But if the package IS NOT present in Import-Package
(or is marked with resolution=optional) then the bundle will be resolved
(naturally).
But in the second case I can use the classes from this package from inside the
bundle! So I don't have package in Import-Package, but I can use classes from
this package! But when I have package in Import-Package I can't use classes
(the bundle is not even resolved)!
It seems to me there is inconsistency here between bundle resolution process
and classloading.
Yes, I know that if I use FRAMEWORK_SYSTEMPACKAGES property and put all my
third-party packages into it the bundle resolution will work just fine.
So as far as I understand there are 3 ways to make third libraries available to
all my bundles:
1. put all the packages from those libraries into FRAMEWORK_SYSTEMPACKAGES property
and set FRAMEWORK_BOOTDELEGATION to "*"
2. put all the libraries (jars) into a separate bundle
3. set FRAMEWORK_BOOTDELEGATION to "*" and remove packages of those
third-party jars from Import-Package entry from all bundle's manifests (or mark them with
resolution=optional)
I don't like the first case because I need to extract package names from all
those third-party jars at build time and somehow pass this information to my
java code which starts felix so that I can put it into FRAMEWORK_SYSTEMPACKAGES
property.
I don't like the second case because I end up with one huge bundle which
contains all the third-party libraries. I don't like it for several reasons,
one being load time and another pure aesthetics.
I don't like the third case because that is not how it is supposed to be used
and basically is a hack.
Am I missing anything? What is the "official" way of achieving it?
Thank you!
--
Dmitry Skavish
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
