You cannot mix Jersey 2.x and 1.x in general under a single class loader. The problem is not so much with Jersey but with JAX-RS. You cannot have JAX-RS 1.1 and JAX-RS 2.0 on the classpath at the same time. Such configuration is not supported.
i'm not sure about your runtime, as you are not mentioning it, but in order to make partial migration from JAX-RS 1.1 and Jersey 1.x to JAX-RS 2.0 and Jersey 2.x, you need to ensure that the migrated parts are isolated from the rest of the application that is yet to be migrated at class loader level. The migrated parts need to use different class loader that loads the new Jersey 2.x + dependencies. The yet to be migrated part then need to use a separate class loader that loads the Jersey 1.x + dependencies. This obviously means that these two parts cannot have any direct Java API dependencies, i.e. you cannot use the un-migrated classes from the migrated code and vice versa.
Marek
On 03 Apr 2014, at 16:42, Behrooz Nobakht <nobeh5_at_gmail.com> wrote:
> Hello,
>
> The situation that we’re facing in a few of our modules is the following that there a dependency between modules as:
>
> M1 depends on M2
> M1 depends on M3
> M3 and M2 are more fundamental services that M1 is dependent upon. We’ve been able to develop (migrate) M3 to Jersey 2.x. M3 also provides a JAX-RS client that is also based on Jersey 2.x. On the other hand, migrating M2 from Jersey 1.x to 2.x requires a lot of effort with integration testing. M2 also provides a JAX-RS client that is based on Jersey 1.x.
>
> Now, the question is that M3 depends on the JAX-RS clients from M2 and M3 that use different versions of Jersey. Is this possible? Any known issues? If OK to mix Jersey 1.x and 2.x, what are the necessary precautions or notes that we need to make sure not to put functionality/performance of M1 at risk?
>
> Thanks in advance,
> Behrooz
>