On 03/18/2009 06:20 PM, Richard S. Hall wrote:
And if you can do that, you should:
D'oh! That should say, "And if you CAN'T do that..."
-> richard
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
