Community
Participate
Working Groups
We picked up javax.annotation 1.1.0 from Orbit as part of Eclipse 4.1 SDK, and it causes us a blocking behavioural failure because of a class-loading issue with javax.annotation.PostConstruct. See bug 348123 We normally use javax.annotation 1.0.0 which specifies "Require-Bundle: system.bundle". That means the bundle is used in java 1.5 and the system JRE_LIB is used when running in java 1.6 (which contains 1.0). javax.annotation 1.1.0 doesn't specify the system.bundle ... probably deliberately. But because it is in the system JRE_LIB in 1.6 some bundles were wired to the system lib and some bundles were wired to the bundle. When running on java 1.7 it doesn't seem like javax.annotation_1.1.0 will defer to the 1.7 JRE_LIB (which contains 1.1). I don't have any answers, but I would like to start talking about the implications of using the javax.annotation 1.1.0 bundle. We're exploring options (tight version ranges) to wire ourselves up to one version or the other in bug 348123 PW
Tom, did you say there was a way now to specify that the javax.annotation bundle should be used when JVM < 1.7, as opposed to requiring the system.bundle which would (in theory) pick the system javax.annotation 1.0 package on a 1.6 JVM? PW
Firstly, please note that Virgo pre-req's Java 6. We do not support Java 5 or Java 7. Virgo contains javax.annotation 1.0.0 from the SpringSource Enterprise Bundle Repository (EBR). This bundle does not specify "require-bundle: system.bundle" and contains and exports the packages javax.annotation and javax.annotation.security at version 1.0.0. Virgo also specifies the following for Java 6 (in lib/java6-server.profile): org.osgi.framework.system.packages = \ ... javax.annotation,\ javax.annotation;version="1.0.0",\ javax.annotation.processing,\ ... The EBR contains the Orbit version of javax.annotation 1.1.0. This bundle does not specify require-bundle: system.bundle and contains and exports the packages javax.annotation, javax.annotation.security, and javax.annotation.sql at version 1.1.0. So I don't think there is an issue here for Virgo. Closing for now. If you can supply a testcase that fails with Virgo on Java 6, please re-open. Feel free to take up general discussion on this topic on the virgo-dev mailing list.
(In reply to comment #2) > Firstly, please note that Virgo pre-req's Java 6. We do not support Java 5 or > Java 7. While you can say you don't run on Java 6, I don't believe you can say you specifically won't run on any newer version of java. Tom, can they exclude a later version of the JVM from running their stuff? Based on conversations with the OSGI people, it seems that the javax.annotation bundle we have in orbit is incorrect. It leads to "sometimes this might or might not work", the worst kind of problem. While the resolution to this might be "there's nothing we can do" I don't think you can close this until you can say the version of javax.annotation you checked into orbit is valid. PW
Hi Paul (In reply to comment #3) > (In reply to comment #2) > > Firstly, please note that Virgo pre-req's Java 6. We do not support Java 5 or > > Java 7. > > While you can say you don't run on Java 6, I don't believe you can say you > specifically won't run on any newer version of java. Er, we do run on Java 6. Virgo would probably run ok on Java 7, but we haven't tested it there and we don't provide a Java 7 profile, so it's certainly not a platform we currently support (i.e. accept and fix bugs against). > > Tom, can they exclude a later version of the JVM from running their stuff? > > Based on conversations with the OSGI people, it seems that the javax.annotation > bundle we have in orbit is incorrect. It leads to "sometimes this might or > might not work", the worst kind of problem. > > While the resolution to this might be "there's nothing we can do" I don't think > you can close this until you can say the version of javax.annotation you > checked into orbit is valid. I think there's some confusion. Virgo has not checked any bundles into Orbit, so we are not responsible for any bugs in Orbit. > > PW Regards, Glyn
(In reply to comment #4) > I think there's some confusion. Virgo has not checked any bundles into Orbit, > so we are not responsible for any bugs in Orbit. I was just reviewing my CQs and came to the same conclusion ... I'll be moving along and taking my bug with me. Sorry for the confusion (which was all mine). PW
(In reply to comment #5) > (In reply to comment #4) > > > I think there's some confusion. Virgo has not checked any bundles into Orbit, > > so we are not responsible for any bugs in Orbit. > > I was just reviewing my CQs and came to the same conclusion ... I'll be moving > along and taking my bug with me. > > Sorry for the confusion (which was all mine). > > PW Phew, that's a relief. ;-)
I am happy to do any modifications that makes the bundle more useful. Note that the bundle works fine for Virgo and for Jetty. I tested the PostConstruct annotation with jetty-7 and everything worked out of the box.
I was talking to Tom about how to make this correct in Orbit. Maybe this is an Orbit bug (that we have to do the work on). From bug 348123 comment #13 you can see that as this package evolves it doesn't interact well with the different JREs: 1.5) doesn't have the package 1.6) has version 1.0, but exported as 0.0.0 1.7) has version 1.1, but exported as 0.0.0 Based on our conversations, the best way to set this up: 1) remove mention of system.bundle from javax.annotation 1.0 2) have both javax.annotation 1.0 and 1.1 import and export their packages at the same version 3) make both javax.annotation bundles singletons 4) users of this package must use Import-Package: with a version (1.0.0 would be sufficient for most purposes). PW
(In reply to comment #7) > I am happy to do any modifications that makes the bundle more useful. > Note that the bundle works fine for Virgo and for Jetty. > I tested the PostConstruct annotation with jetty-7 and everything worked out of > the box. Please note that Virgo does not use the Orbit version of javax.annotation 1.0.0. Virgo uses the com.springsource variant from the SpringSource EBR.
I am going to move this to orbit since I think that is the proper place to discuss fixes to the javax.annotation orbit bundles. I agree with comment 8. I think for most cases, as long as the bundles use Import-Package for javax.annotation packages AND they specify version=1.0 then things will work fine. We will run into issues if both versions of javax.annotation bundles are installed because they do not export AND import their packages. I opened bug348203 to update the VM profiles in the framework so that it can export the proper versions of the javax.annotation packages. This will allow for the packages provided by the VM to be used as a substitute for the exports from the javax.annotation bundles (once they import what they export). For now I think this is a Juno exercise (perhaps Indigo SR1). For now I would recommend all bundles that need javax.annotation to use Import-Package: javax.annotation; version=1.0 (or 1.1 if they really need it)
(In reply to comment #9) > (In reply to comment #7) > > I am happy to do any modifications that makes the bundle more useful. > > Note that the bundle works fine for Virgo and for Jetty. > > I tested the PostConstruct annotation with jetty-7 and everything worked out of > > the box. > > Please note that Virgo does not use the Orbit version of javax.annotation > 1.0.0. Virgo uses the com.springsource variant from the SpringSource EBR. Violeta (miles78) told me on the chat that she tried both javax.el-2.2 and javax.annotation-1.1. She was kind enough to catch the fact that I had confused some CQ numbers in the Orbit IPLogs. This is why I stated that Virgo was working fine with this version of javax.annotation.
No problem Hugues. Just trying to keep the record straight to avoid (more) confusion.
(In reply to comment #1) > Tom, did you say there was a way now to specify that the javax.annotation > bundle should be used when JVM < 1.7, as opposed to requiring the system.bundle > which would (in theory) pick the system javax.annotation 1.0 package on a 1.6 > JVM? > > PW There is a new way to do this using capabilities in OSGi R4.3 (Equinox 3.7-Indigo). For example, we could change the javax.annotation 1.0 version of the bundle such that it only resolved on VMs < Java6. The following header would achieve this: Require-Capability: osgi.ee; filter:="(&(osgi.ee=JavaSE)(!(version>=1.6))(version>=1.5))" Similarly the javax.annotation 1.1 version of the bundle could add this: Require-Capability: osgi.ee; filter:="(&(osgi.ee=JavaSE)(!(version>=1.7))(version>=1.5))" Forgive the obtuse filter, since LDAP only has >= and <= and no < or > you are forced to do this kind of opposite check evaluate version<X While this may be nice to do, I don't think it is strictly necessary if we export AND import the javax.annotation packages to allow for substitution. It would also be quite bad without the fix to bug348203 because then all we would end up with is the javax.annotation packages exported by the system.bundle but with version=0.0.0. That would cause all bundles that use Import-Package: javax.annotation; version=1.0 to fail to resolve.
(In reply to comment #9) > > Please note that Virgo does not use the Orbit version of javax.annotation > 1.0.0. Virgo uses the com.springsource variant from the SpringSource EBR. doesn't that mean that installing Virgo on eclipse pulls in a different bundle that exports javax.annotation, and could potentially lead to conflicts? SpringSource EBR also provides 2 javax.annotation bundles: com.springsource.javax.annotation-1.0.0.jar This doesn't mention system.bundle, and has: Export-Package: javax.annotation;version="1.0.0",javax.annotation.secu rity;version="1.0.0" javax.annotation-1.1.0.v201105051105.jar This is the orbit version they are re-providing.
(In reply to comment #14) > doesn't that mean that installing Virgo on eclipse pulls in a different bundle > that exports javax.annotation, and could potentially lead to conflicts? This might just be a red-herring, as Virgo is about a server runtime, not eclipse IDE tools. PW
(In reply to comment #13) > There is a new way to do this using capabilities in OSGi R4.3 (Equinox > 3.7-Indigo). For example, we could change the javax.annotation 1.0 version of > the bundle such that it only resolved on VMs < Java6. The following header > would achieve this: > > Require-Capability: > osgi.ee; filter:="(&(osgi.ee=JavaSE)(!(version>=1.6))(version>=1.5))" > > Similarly the javax.annotation 1.1 version of the bundle could add this: > > Require-Capability: > osgi.ee; filter:="(&(osgi.ee=JavaSE)(!(version>=1.7))(version>=1.5))" > > Forgive the obtuse filter, since LDAP only has >= and <= and no < or > you are > forced to do this kind of opposite check evaluate version<X > > While this may be nice to do, I don't think it is strictly necessary if we > export AND import the javax.annotation packages to allow for substitution. It > would also be quite bad without the fix to bug348203 because then all we would > end up with is the javax.annotation packages exported by the system.bundle but > with version=0.0.0. That would cause all bundles that use Import-Package: > javax.annotation; version=1.0 to fail to resolve. Thanks so much for the explanations! bug 348203 seems to completely prevent us from using the Require-Capability filter until 3.8. I am not entirely clear: will exporting AND importing the version-ed packages fix the issue even before bug 348203 is fixed? So importing and exporting the packages is absolutely required here: Export-Package: javax.annotation;version="1.0.0", javax.annotation.security;version="1.0.0", javax.annotation.sql;version="1.0.0" Import-Package: javax.annotation;version="1.0.0", javax.annotation.security;version="1.0.0", javax.annotation.sql;version="1.0.0" Finally understanding this: http://www.osgi.org/blog/2007/04/importance-of-exporting-nd-importing.html Let me know if the rest of this discussion is out of the scope of this bug: The bundles I maintain at Orbit have not followed this practice and neither does the bundles with which I had so much trouble when I started to work on OSGi without the boot delegation. For example, both javax.xml and javax.xml.stream use the Require-Bundle: system.bundle technique and only export version-ed packages Is bug 348203 something that should also apply to other packages? For example: JavaSE-1.6.profile: ... javax.xml.stream,\ javax.xml.stream.events,\ javax.xml.stream.util,\ .... org.xml.sax,\ org.xml.sax.ext,\ org.xml.sax.helpers Should it in fact export version 2.0.2 for org.sax and 1.0.1 for javax.xml.stream? In jetty (JDK5 and up) I am still puzzled as to whether we should import javax.xml.* and org.sax with or without a version. At the moment we are not specifying the version. But that leads to some confusion and I suspect some harmful class-spaces separations later when a bundle does import those packages with a version.
(In reply to comment #16) > > Thanks so much for the explanations! > > bug 348203 seems to completely prevent us from using the Require-Capability > filter until 3.8. Correct, and I am not suggesting we start using Require-Capability anyway in this case. > I am not entirely clear: will exporting AND importing the version-ed packages > fix the issue even before bug 348203 is fixed? > > So importing and exporting the packages is absolutely required here: > Export-Package: javax.annotation;version="1.0.0", > javax.annotation.security;version="1.0.0", > javax.annotation.sql;version="1.0.0" > Import-Package: javax.annotation;version="1.0.0", > javax.annotation.security;version="1.0.0", > javax.annotation.sql;version="1.0.0" Yes, this should help because it allows the javax.annotation exports be substituted with the javax.annotation exports from the 1.1.0 version. > > Finally understanding this: > http://www.osgi.org/blog/2007/04/importance-of-exporting-nd-importing.html > > Let me know if the rest of this discussion is out of the scope of this bug: > > The bundles I maintain at Orbit have not followed this practice and neither > does the bundles with which I had so much trouble when I started to work on > OSGi without the boot delegation. > > For example, both javax.xml and javax.xml.stream use the Require-Bundle: > system.bundle technique and only export version-ed packages > > Is bug 348203 something that should also apply to other packages? > For example: JavaSE-1.6.profile: > ... > javax.xml.stream,\ > javax.xml.stream.events,\ > javax.xml.stream.util,\ > .... > org.xml.sax,\ > org.xml.sax.ext,\ > org.xml.sax.helpers > Should it in fact export version 2.0.2 for org.sax and 1.0.1 for > javax.xml.stream? This would be very nice, but only works if we can somehow get a list of versions for each package in the VM profiles. So far this information has been very hard to come by. Perhaps the folks maintaining the various orbit bundles that include versions of the packages also included in the VM versions can help. > > In jetty (JDK5 and up) I am still puzzled as to whether we should import > javax.xml.* and org.sax with or without a version. > At the moment we are not specifying the version. > But that leads to some confusion and I suspect some harmful class-spaces > separations later when a bundle does import those packages with a version. Unfortunately, unless we can get a definitive answer for the package versions shipped with the various versions of Java SE it will be difficult to do something different. Perhaps we should open a separate orbit bug to gather the list of such packages and then start to determine what we think the versions should be. Then I can update the VM profiles provided by Equinox to provide the most accurate package versions possible. But yes, this is out of scope for this bug.
(In reply to comment #17) > > > > So importing and exporting the packages is absolutely required here: > > Export-Package: javax.annotation;version="1.0.0", > > javax.annotation.security;version="1.0.0", > > javax.annotation.sql;version="1.0.0" > > Import-Package: javax.annotation;version="1.0.0", > > javax.annotation.security;version="1.0.0", > > javax.annotation.sql;version="1.0.0" OK will mark this bug as fixed once this is committed and Indigo is out again. > This would be very nice, but only works if we can somehow get a list of > versions for each package in the VM profiles. So far this information has been > very hard to come by. Perhaps the folks maintaining the various orbit bundles > that include versions of the packages also included in the VM versions can > help. > > > > > In jetty (JDK5 and up) I am still puzzled as to whether we should import > > javax.xml.* and org.sax with or without a version. > > At the moment we are not specifying the version. > > But that leads to some confusion and I suspect some harmful class-spaces > > separations later when a bundle does import those packages with a version. > > Unfortunately, unless we can get a definitive answer for the package versions > shipped with the various versions of Java SE it will be difficult to do > something different. Perhaps we should open a separate orbit bug to gather the > list of such packages and then start to determine what we think the versions > should be. Then I can update the VM profiles provided by Equinox to provide > the most accurate package versions possible. But yes, this is out of scope for > this bug. OK, understood, just knowing that in fact this would be a proper solution is great help. Speaking for jetty we would be quite interested in this endeavor. I am sure other RT projects are likely to be interested in this too.
(In reply to comment #18) > > OK, understood, just knowing that in fact this would be a proper solution is > great help. > Speaking for jetty we would be quite interested in this endeavor. > I am sure other RT projects are likely to be interested in this too. I decided to open a framework bug348630 to update the profiles for the VMs in the equinox framework. I will post a note to orbit-dev asking for orbit committers help in determining which VMs export the same package that their own orbit bundles export and help determine the different versions.
What a long confusing bug :) ... well, confusing for skim readers like me. But, I think Hugues is the right person to assign it to ... let me know if it should be someone else.
What's the next step here? Am I going to have to read it closely and actually understand the issues involved? :)
(In reply to comment #21) > What's the next step here? > > Am I going to have to read it closely and actually understand the issues > involved? :) This bug is getting dusty and no one complained about it for quite a while or suggested a clear solution. Anyone still annoyed with this?
> Anyone still annoyed with this? I am. For the original reasons. I opened bug 387250 so we in platform could move up to the most recent version. (I by chance noticed we were not ... no huge need I know of other than to be current and consistent with what others may be delivering, but, it sounds like, there may be issues with Java 7, especially if both bundles are present?). So, let's see if we can get Tom to suggest a clear solution :) First, to clarify Tom mentions work needed for bug 348203 but that's been closed as a dup of bug 348630 and that bug is still targeted to Juno SR1. Not sure of its status, Tom?, but I am more worried about Kepler, for updating the Platform's pre-req. Second, It sounds like you, Hugues, spelled out the right fix in comment 18: > > So importing and exporting the packages is absolutely required here: > > Export-Package: javax.annotation;version="1.0.0", > > javax.annotation.security;version="1.0.0", > > javax.annotation.sql;version="1.0.0" > > Import-Package: javax.annotation;version="1.0.0", > > javax.annotation.security;version="1.0.0", > > javax.annotation.sql;version="1.0.0" > OK will mark this bug as fixed once this is committed and Indigo is out again. So ... I think we need the export that you import change (assuming for both 1.0.0 and 1.1.0 ... but haven't checked if either has it yet). I think the only remaining question is if the "system.bundle" should be removed from the 1.0.0 version? (I think so). Sounds like it'd be worth a try for Kepler M2? That'd give a few milestones for complications to be found?
(In reply to comment #23) > > Anyone still annoyed with this? > > I am. For the original reasons. I opened bug 387250 so we in platform could > move up to the most recent version. (I by chance noticed we were not ... no > huge need I know of other than to be current and consistent with what others > may be delivering, but, it sounds like, there may be issues with Java 7, > especially if both bundles are present?). > > So, let's see if we can get Tom to suggest a clear solution :) I wish I had the magic bullet here. The best solution for the moment is to do what Paul suggests in comment 8 and I think reiterated in comment 18. > > First, to clarify Tom mentions work needed for bug 348203 but that's been > closed as a dup of bug 348630 and that bug is still targeted to Juno SR1. > Not sure of its status, Tom?, but I am more worried about Kepler, for > updating the Platform's pre-req. I mentioned opening bug 348630 in comment 18. Unfortunately I doubt this will make progress for SR1. But that does not mean we cannot do the suggested fixes in comment 8 and comment 18. > > Second, It sounds like you, Hugues, spelled out the right fix in comment 18: > > > > So importing and exporting the packages is absolutely required here: > > > Export-Package: javax.annotation;version="1.0.0", > > > javax.annotation.security;version="1.0.0", > > > javax.annotation.sql;version="1.0.0" > > > Import-Package: javax.annotation;version="1.0.0", > > > javax.annotation.security;version="1.0.0", > > > javax.annotation.sql;version="1.0.0" > > > OK will mark this bug as fixed once this is committed and Indigo is out again. > > So ... I think we need the export that you import change (assuming for both > 1.0.0 and 1.1.0 ... but haven't checked if either has it yet). > > I think the only remaining question is if the "system.bundle" should be > removed from the 1.0.0 version? (I think so). > > Sounds like it'd be worth a try for Kepler M2? That'd give a few milestones > for complications to be found? I agree.
Hugues, If you don't mind, I'll take this bug. I'll make the changes for 1.0 and 1.1 and see if I can do some sanity check with the unit test mentioned in bug 348123. If all goes well, in a week or two promote in an Orbit I build and send note to cross-project list for others to be sure to "test early" if they use 1.0 or 1.1. Thanks, all. [And, seriously, Hugues ... if you really want it ... feel free to take it back ... don't mean to usurp your favorite tasks. :)]
Created attachment 220766 [details] patch for both version of javax.annotation removes the "rerquire system bundle" and does "import what you export" pattern. (Note, the package names are not quite what were listed previously, for "1.0.0", so let me know if I've misunderstood, or looking at wrong thing, but suspect it was just a "typo").
I've made these changes ... now to find someone to verify they help, enough. :) Watch for comments in bug 387250.
(In reply to comment #27) > I've made these changes ... now to find someone to verify they help, enough. > :) > > Watch for comments in bug 387250. On the surface, this didn't seem to work right for Eclipse N build. See bug 387250. Its too early to say exactly why, but am re-opening this since not sure things are right and may need to re-add "require system bundle"?
moving back to fixed. In the platform build, turned out there was a simple explanation why it failed. So I suspect this is still correct.
