geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick McGuire <rick...@gmail.com>
Subject Re: Understanding the "partial=true; mandatory:=partial" trick
Date Wed, 09 Dec 2009 10:40:31 GMT
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
>
>   


Mime
View raw message