Dependency conflict

[akurniawan]

Hi, thanks for the driver!

We encounter a problem with your consul-client, because apparently your driver requires javax.ws.rs.core as one of the dependencies. Unfortunately, we also using hadoop client that requires jersey-core plugin which implements also javax/ws/rs/core/Response.class, and jersey-core plugin used by hadoop is the old one (version 1.9). With jersey plugin there we can't use your driver as it will give us an errror "NoSuchMethodException" from Response.class because the jersey plugin doesn't contain .close() method.
Do you have any work-around for this? thanks

[rickfast]

I can't think of one off the top of my head unfortunately. JAX-RS seemed like a good idea initially, and it's worked out great for some clients. Ultimately, I need to rework the client to either A. have minimal dependencies or B. use a shaded JAR for the basic dependencies. I can try to relocate JAX-RS and Jackson into the com.orbitz package and ship them in the shadow JAR, which would allow other versions of JAX-RS to live on the classpath. I'll try to find time in the near future to try the shaded JAR idea.

[Lavignotte]

Hi,

I faced the same problem a few days ago in a Maven project and solved it by placing consul-client and javax.ws.rs.core dependencies at the top of the pom.xml file.
This way the classloader takes the correct version of the Response class in priority.
Hope this helps !
Unless Hadoop needs its specific version...

Pierre

[rickfast]

I've removed JAX-RS in version 0.11.0. The new HTTP client is shaded into the JAR, so it shouldn't cause any classpath issues