Jarek Gawor wrote:
Hey,
I've ran into another split package problem in OpenEJB and I'm trying
to understand the "partial=true; mandatory:=partial" trick. So I
wanted to double check my understanding of this with OSGi experts
here.
First of all, if an exported package is marked with "partial=true;
mandatory:=partial", the importers wanting to wire to a bundle that
exports that package must provide that mandatory attribute on its
Import-Package import. For example, if we have a bundle A with
Export-Package: org.apache.geronimo.foo;partial=true;
mandatory:=partial" the importer would have to have Import-Package:
org.apache.geronimo.foo;partial=true to wire to bundle A. And that
means that "partial" attribute really has no special meaning in OSGi.
We could have easily archived the same exact result if we marked a
package with "a=b; mandatory:=a". Is my understanding right so far?
In Geronimo we marked the javax.transaction.xa package with that
partial attribute because the JVM only provides a subset of the
classes in that package. And now all imports on the xa package will be
automatically wired to the Geronimo JTA spec bundle. And since the
Geronimo bundle has all the necessary classes all works well.
But what happens if you really have a true split package problem where
subset of the classes are provided by two different bundles? E.g.
bundle 1 provides org.apache.geronimo/classA and bundle 2 provides
org.apache.geronimo/classB. That's the problem in OpenEJB in
org.apache.openejb.client package. Some client classes are exported in
openejb-core bundle and some in openejb-client bundle.
The best solution is of course the remove the split package problem in
the first place. But if that's not possible, another solution is to
combine the mandatory attribute trick with Require-Bundle. That is,
bundle 1 exports package X with some mandatory attribute and bundle 2
has Require-Bundle on bundle 1 (and also exports package X). So all
imports on package X would always be wired to bundle 2 and bundle 2
would have access to all classes in package X. Do I have that right?
OpenEJB seems to be following the Require-Bundle/partial attribute
solution but it's definitely not set up right (assuming I understand
that solution correctly).
Are there better solutions for the split package problem?
I think your analysis is correct, at least as far as I've investigated
this. This is only a "trick" in the sense that this notation is used to
essentially remove the JVM provided transaction classes from automatic
wiring consideration with the split package situation.
As defined in core, this notation is there to allow for a split package
situation, but to take advantage of it, Require-Bundle is a necessary to
perform the wiring. Given that these classes are part of the jee APIs
that need to be made available to all jee apps, I'm not sure this is a
good approach. The best approach would be to see if the split bundle
packaging can be fixed. I'm guessing these might be openejb
implementation classes, so it could be fairly easy to correct.
The only other solution I've found for this problem is to place the
bundles in question on the application class path (i.e., on the endorsed
or ext path) and then have the system bundle export them.
Jarek
