Leo/Marek -
I tried these procedures to update a GFv3.0.1 install to Jersey 1.5. I tried
both the app server upgrade and the WAR file upgrade approach an they both
failed. I posted recently on this (last Monday). The only advice was from
someone who said they had the same issues I did and they just decided to go
directly to GF3.1 which has Jersey 1.5 bundled.
-Noah
On Tue, Mar 8, 2011 at 8:52 AM, Marek Potociar <marek.potociar_at_oracle.com>wrote:
> Did you try to follow the Jersey users guide that talks about how to
> override Jersey in GF?
>
> http://jersey.java.net/nonav/documentation/latest/user-guide.html#d4e1868
>
> Marek
>
> On 03/07/2011 05:14 PM, Leo Romanoff wrote:
> > Hi,
> >
> > I'm facing the following problem.
> >
> > I have an EAR file that uses the latest version of Jersey. If I build the
> > EAR to include the latest Jersey libs, it deploys just fine on those
> builds
> > of the GF application server, which do not contain Jersey libs by
> default.
> >
> > Unfortunately, some of the GF builds that are used by our customer in
> > production include older versions of Jersey. In this case, EAR deployment
> > fails due to incompatibilities and conflicts between Jersey versions.
> >
> > I've read this explanations about upgrading Jersey on Glassfish:
> > http://jersey.java.net/nonav/documentation/latest/glassfish.html ,
> > but it assumes that I'm allowed to modify Glassfish settings or even the
> > global libs directory, which is not the case in my scenario ;-(
> >
> > I'd like to be able to use the required version of Jersey with my EAR
> file
> > even if Glassfish already provides its own Jersey. And I'd like to
> achieve
> > it only by means of creation of a proper EAR (eventually with some
> special
> > descriptors, etc). Is it possible???
> >
> > I was thinking e.g. about using Maven shade plugin with its relocate
> > feature:
> >
> http://maven.apache.org/plugins/maven-shade-plugin/examples/class-relocation.html
> >
> http://www.javabeat.net/articles/185-apache-maven-20-maven-plugins-3.html
> >
> > I guess, with it the class renaming should not be an issue. But I'm not
> so
> > sure about different XML descriptors and the like. I have the feeling,
> that
> > Jersey internally uses some string constants which refer original
> Jersey's
> > class or package names and they would stop working properly after
> renaming.
> > Or am I wrong and someone managed to use this renaming trick with Jersey?
> >
> > I'm very interested in any suggestions!
> >
> > Thanks,
> > Leo
> >
> > --
> > View this message in context:
> http://jersey.576304.n2.nabble.com/How-to-use-a-specific-version-of-Jersey-with-your-EAR-if-appserver-includes-an-older-version-of-Jersy-tp6097868p6097868.html
> > Sent from the Jersey mailing list archive at Nabble.com.
>