dantran wrote: > > sorry about the noise, I am able to give javax.annotation a version > under etc/jre.properties and my activemq client works without the need > for geronimo-annotation package > > .... > javax.annotation;version="1.1.1", \ > javax.annotation.processing;version="1.1.1", \ > > > Thanks for all the helps > > -Dan > > On Mon, Mar 14, 2011 at 12:41 PM, Dan Tran <[email protected]> > wrote: >> I am a little confused about what to do with jre.properties. Is there >> a way to give it a explicit version ( rather then remove it )? >> >> javax.annotation;version="1.0.0" \ >> ... >> >> chokes karaf at startup >> >> Thanks >> >> -Dan >> >> >> >> On Mon, Mar 14, 2011 at 10:16 AM, karafman >> <[email protected]> wrote: >>> >>> karafman wrote: >>>> >>>> >>>> jb-3 wrote: >>>>> >>>>> Hi, >>>>> >>>>> it depends of your etc/jre.properties configuration. If >>>>> etc/jre.properties (for jre-1.6) contains javax.annotation, it means >>>>> that the javax.annotation is provided by the JDK. If it's commented >>>>> (as >>>>> we have in ServiceMix), it means that javax.annotation is provided by >>>>> an >>>>> "external" bundle, such as Geronimo specs. >>>>> >>>>> So do you use the JDK or the external bundle for javax.annotation ? >>>>> >>>>> Thanks >>>>> Regards >>>>> JB >>>>> >>>>> On 03/13/2011 01:18 AM, Dan Tran wrote: >>>>>> Hi I have a very simple spring power bundle which uses @PostContruct >>>>>> and @PreDestroy. The bundle is built with bundlor-maven-plugin. It >>>>>> works fine at initial try. >>>>>> >>>>>> Then, I add java.annotation's version to the manifest ( >>>>>> bundlor-maven-plugin complains about the mising version). Deploy >>>>>> again >>>>>> with geronimo-annotation's bundle. The PostContruct and PreDestroy >>>>>> stops working. >>>>>> >>>>>> Kara 2.2 does not complain about bundle, every thing looks good. >>>>>> >>>>>> Is there a workaround? This prevents me from deploying and use >>>>>> activemq client ( which also uses geronimo-annotation ) >>>>>> >>>>>> This sounds likes a very fundamental problem, but I am not able to >>>>>> find any existing similar issue yet >>>>>> >>>>>> Big thanks ahead. >>>>>> >>>>>> -Dan >>>>> >>>> >>>> Another item to consider is the version number of the javax.annotations >>>> package you'd like to use. All packages in the jre.properties file are >>>> made available under version 0.0.0. If you are using an external >>>> javax.annotations package for your application, simply identifying the >>>> version number of the javax.annotations packages will tell karaf to NOT >>>> use the jre.properties defined javax.annotations package. For example, >>>> using the following will allow you to use the jsr250-api for >>>> annotation: >>>> >>>> javax.annotation >>>> jsr250-api >>>> 1.0 >>>> >>>> >>>> Then, in your maven-bundle-plugin you'd have the following in your >>>> section to use this version of javax.annotation: >>>> >>>> javax.annotation;version=1.0; >>>> >>>> Its been my experience that removing stuff from your jre.properties >>>> file >>>> can have unforeseen results, and unless you can't differentiate between >>>> packages using the version number, you really shouldn't remove packages >>>> from it. >>>> >>> >>> It looks like my posting voodoo is bad. This should better explain what >>> I >>> was trying to show you: >>> >>> >>> javax.annotation >>> jsr250-api >>> 1.0 >>> >>> >>> >>> ----- >>> Karafman >>> Slayer of the JEE >>> Pounder of the Perl Programmer >>> >>> -- >>> View this message in context: >>> http://karaf.922171.n3.nabble.com/javax-annotation-weirdness-tp2671048p2676689.html >>> Sent from the Karaf - User mailing list archive at Nabble.com. >>> >> >
Dan, There's been quite a bit of debate both for and against using explicit versioning in the jre.properties file. The arguments are as follows. For: Explicitly defining version numbers in the jre.properties file will allow users to define the version of specific packages they want to use. Against: the jre.properties file is set up to allow users to move from one version of Java to another without needing to modify all of the jre import statements in thier bundles. In my opinion, explicit versioning in the jre.properties file can lead to some very serious negative side effects when deploying and maintaining a network of Karaf instance in an operational environment. The problems arise when you attempt to deploy a newer version of your application (with updated dependencies) into an existing operational karaf instance. For example, lets say your application winds up being deployed to 50 nodes, and you are able to successfully upgrade your application in 41 of them over a few year's time period. You then update your application again, but decide that you want to use a newer version of javax.annotation, because you want to use @dantransAnnotation. You tar up for bundles, or create a feature or whatever to deploy your new application, and some of the sites work and some don't. Oh, and you go on vacation right after you make your upgrade available. All the sudden every instance of Karaf that has javax.annotation's version explicitly defined in the jre.properties file doesn't appear to work, and you end up having to manually update the jre.properties files from your cruise ship in the mediterranean. Oh the horror! Instead of specificying your version of javax.annotation in jre.properties, just leave it the way it is. Set your provisioning to deploy the version of javax.properties you want to use, and then wire to it using its unique version number. That way you won't get into hot-water on that cruise because you're working instead of hanging out with your pals! BTW, I'm a strong proponent of not doing anything to the jre.properties file unless it is absolutely necessary. ----- Karafman Slayer of the JEE Pounder of the Perl Programmer -- View this message in context: http://karaf.922171.n3.nabble.com/javax-annotation-weirdness-tp2671048p2694442.html Sent from the Karaf - User mailing list archive at Nabble.com.
