Hi Leo,
I believe the main issue is with the API classes clashing, rather than
impl. classes. So I am quite confident you would be facing the same
issue even when trying to use REST Easy.
The thing is, GF does not allow to override javax packages and
unfortunately, it is sharing the same classloader for a given javax API
with all apps and the GF runtime itself - so, it is not isolated
properly. Once the javax.ws.rs.ext.RuntimeDelegate instance is created
(pointing to whatever Jersey impl is included in GF), you can't make
GlassFish or any other deployed app to use a different version of Jersey
unless you can force GF to give you a separate app-specific classloader
for the javax.ws.rs.* packages. That can be done by using that JVM
property Pavel mentioned. Anyway, since you can't do it, probably the
only thing you can try is using that maven plugin you mentioned to
repackage javax.ws.rs.* packages your app uses to something not starting
with javax.*, make sure you rename the META-INF/services files as well
and see if there is any other issue.
Martin
On 8.3.2011 19:38, Leo Romanoff wrote:
> One alternative that comes to my mind is to use the JBoss REST Easy
> implementation of JAX-RS. Since this one is not included into the Glassfish
> standard libs, it probably won't have conflicts at the class level with GF.
>
> But I'm not sure if GF's prepackaged Jersey can coexist with an alternative
> implementation of JAX-RS...
>
> Has anyone tried something like this?
>
> 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-tp6097868p6134512.html
> Sent from the Jersey mailing list archive at Nabble.com.