Re: Understanding the "partial=true; mandatory:=partial" trick
Hi, thanks for trying that. I guess the difference of your scenario vs. what I've tried before is that your scenario imports the package but also exports the package(like bundle 2) Lin On Thu, Dec 10, 2009 at 4:50 PM, Jarek Gawor wrote: > On Wed, Dec 9, 2009 at 1:06 PM, Lin Sun wrote: >> Hi, >> >> Do we have to use Require-Bundle here? I would think Import-Package >> of packageX with the mandatory attribute should wire bundle 2 to >> bundle 1. >> >> Here's my understanding of your scenario: >> >> Bundle1: >> Export-Package:x;partial=true;mandatory:=partial >> >> Bundle2: >> Import-Package:x;partial=true >> Export-Package:x >> >> >> Any other bundles - should be wired to bundle 2: >> Import-Package:x > > That's a good question. I tried it and it didn't work. I assume it was > because if Bundle 3 was wired to Bundle 2 it was only able to see > classes local to Bundle 2. That is, it acted like the Bundle 2 wasn't > re-exporting the additional classes from Bundle 1. But I guess if > Bundle 2 Required-Bundle: Bundle 1 these additional classes from > Bundle 1 would be visible to Bundle 3. > > Jarek >
Re: Understanding the "partial=true; mandatory:=partial" trick
On Wed, Dec 9, 2009 at 1:06 PM, Lin Sun wrote: > Hi, > > Do we have to use Require-Bundle here? I would think Import-Package > of packageX with the mandatory attribute should wire bundle 2 to > bundle 1. > > Here's my understanding of your scenario: > > Bundle1: > Export-Package:x;partial=true;mandatory:=partial > > Bundle2: > Import-Package:x;partial=true > Export-Package:x > > > Any other bundles - should be wired to bundle 2: > Import-Package:x That's a good question. I tried it and it didn't work. I assume it was because if Bundle 3 was wired to Bundle 2 it was only able to see classes local to Bundle 2. That is, it acted like the Bundle 2 wasn't re-exporting the additional classes from Bundle 1. But I guess if Bundle 2 Required-Bundle: Bundle 1 these additional classes from Bundle 1 would be visible to Bundle 3. Jarek
Re: Understanding the "partial=true; mandatory:=partial" trick
Interesting. I used other mandatory attribute without Require-Bundle fine before. And "partial" here is just same as other mandatory attribute, right? Anyway this should be something quick to try to see if we could avoid Require-Bundle Lin On Wed, Dec 9, 2009 at 1:26 PM, Rick McGuire wrote: > Everything I've seen about using partial=true in the core specification also > indicates that Require-Bundle is necessary to get everything wired up > together. I don't see anything in the core specification that indicates > partial=true has any meaning on an Import-Package. Section 3.12.1 > specifically states: > > "...only bundles using the Require-Bundle header can have split packages." > > Which pretty much states that Require-Bundle needs to be used. > > Rick > > >> Lin >> >> On Tue, Dec 8, 2009 at 11:27 PM, Jarek Gawor wrote: >> >> >>> >>> 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? >>> >> >> > >
Re: Understanding the "partial=true; mandatory:=partial" trick
Lin Sun wrote: Hi, Do we have to use Require-Bundle here? I would think Import-Package of packageX with the mandatory attribute should wire bundle 2 to bundle 1. Here's my understanding of your scenario: Bundle1: Export-Package:x;partial=true;mandatory:=partial Bundle2: Import-Package:x;partial=true Export-Package:x Any other bundles - should be wired to bundle 2: Import-Package:x Everything I've seen about using partial=true in the core specification also indicates that Require-Bundle is necessary to get everything wired up together. I don't see anything in the core specification that indicates partial=true has any meaning on an Import-Package. Section 3.12.1 specifically states: "...only bundles using the Require-Bundle header can have split packages." Which pretty much states that Require-Bundle needs to be used. Rick Lin On Tue, Dec 8, 2009 at 11:27 PM, Jarek Gawor wrote: 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?
Re: Understanding the "partial=true; mandatory:=partial" trick
Hi, Do we have to use Require-Bundle here? I would think Import-Package of packageX with the mandatory attribute should wire bundle 2 to bundle 1. Here's my understanding of your scenario: Bundle1: Export-Package:x;partial=true;mandatory:=partial Bundle2: Import-Package:x;partial=true Export-Package:x Any other bundles - should be wired to bundle 2: Import-Package:x Lin On Tue, Dec 8, 2009 at 11:27 PM, Jarek Gawor wrote: > 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?
Re: Understanding the "partial=true; mandatory:=partial" trick
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
Understanding the "partial=true; mandatory:=partial" trick
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? Jarek
