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.