On Jun 18, 2013, at 6:29 PM, Ian Simpson <ian.g.simpson_at_gmail.com> wrote:
> We have several web services clients that are pulling in jersey-client, which pulls in jersey-core as a transitive dependency. Since the Maven coordinates and package structure for Jersey 1.x and Jersey 2 are different, both need to be on the classpath for compatibility.
>
> There are two cases we're concerned about:
> 1) We have a Jersey 2.0 web service that needs to use client jars from Jersey 1.x services to communicate with them
> 2) We have another application with multiple client jars, some of which potentially being Jersey 2 or Jersey 1.x
>
> If the jax-rs dependency was transitive in Jersey 1.x this wouldn't be a problem, as that could be managed through dependency management and my understanding is that Jersey 1.x can use the jax-rs 2.0 classes.
While the above is true - linking phase during JVM bootstrap should succeed - note however that Jersey 1.x does not implement some of the required SPIs as well as many new methods on Response and Response.ResponseBuilder APIs etc. So you are potentially heading for a nasty collection of class-loading and unsupported operation exceptions at runtime.
>
> There's a cost to updating all of our Jersey 1.x services to 2.0, and one that we cannot afford up front; we need to be able to update as we have opportunities to do so.
I'd suggest to split your application into set of modules and then migrate those modules at a convenient pace one by one. Use application classloader isolation to workaround the issues with multiple JAX-RS API and Jersey libs on the class path.
>
> Again, I'm questioning if I'm overlooking some glaring issue here, so feel free to set me straight if I am :)
Unfortunately, there is no easy way of migrating from proprietary Jersey 1.x APIs to standard JAX-RS 2.0 APIs at the moment. I cannot think of a better solution than modularising your large app into multiple modules and then migrate those modules individually.
Marek
>
>
> On Tue, Jun 18, 2013 at 9:23 AM, Marek Potociar <marek.potociar_at_oracle.com> wrote:
> Hi,
>
> Please feel free to file a new issue against Jersey 1.x. We do not however have any immediate plans to release new Jersey 1.x version that would fix the issue. Just curious - what forces you to have both Jersey 1.x and JAX-RS 2.0 on the same class path?
>
> Marek
>
> On Jun 17, 2013, at 7:26 PM, Ian Simpson <ian.g.simpson_at_gmail.com> wrote:
>
>> I'm looking at using Jersey 2.0 and I'm trying to tackle the issue of having both the 1.x and 2.x jax-rs classes within the same classpath.
>>
>> The jersey-core Maven dependencies for 1.x all bundle the jax-rs classes inside, which is undesirable from a class loading standpoint when using Jersey 2.x since you need jax-rs 2.0. There's an excellent blog post outlining this concern here: http://sleeplessinslc.blogspot.com/2012/10/jax-rs-20-jersey-20-preview-example.html
>>
>> JUnit has a similar issue with including hamcrest, which creates issues if you use Maven to block duplicate classes. There's also a junit-dep jar that's available which doesn't include this package.
>>
>> Can a similar thing be done retroactively and deployed to Maven central for the Jersey 1.x jars? Perhaps create a jersey-core-nodeps or something along those lines? I could repackage the jars myself and upload them to my organization's internal Nexus instance, but it would be preferable to have them available via Central.
>>
>> I'm also open to the fact that I may be missing the obvious solution or an easy alternative. If that's the case please call out my obliviousness.
>
>