Migrate to clean JAX-RS 2.0 API and remove proprietary dependencies

[grexe]

(related to #107 and #122)
The DockerClient still has dependencies on Jersey that make it really hard (nearly impossible) to use the docker client library in environments that depend on other REST implementations, e.g. Wildfly that is built on RESTeasy, checked sources for version 3.6.8 (fortunately it's all in one place,-):

DefaultDockerClient.java:import org.glassfish.jersey.apache.connector.ApacheClientProperties;
DefaultDockerClient.java:import org.glassfish.jersey.apache.connector.ApacheConnectorProvider;
DefaultDockerClient.java:import org.glassfish.jersey.client.ClientConfig;
DefaultDockerClient.java:import org.glassfish.jersey.internal.util.Base64;
DefaultDockerClient.java:import org.glassfish.jersey.jackson.JacksonFeature;

Maven side dependencies on Jersey:

<dependency>
<groupId>org.glassfish.jersey.core</groupId>
<artifactId>jersey-client</artifactId>
<version>2.19</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.connectors</groupId>
<artifactId>jersey-apache-connector</artifactId>
<version>2.19</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.media</groupId>
<artifactId>jersey-media-json-jackson</artifactId>
<version>2.19</version>
</dependency>

Interestingly, the client works for some commands (like looking up, starting or stopping containers), but fails for others (like reading logs or executing commands), I guess only the failing commands use some Jersey specific calls.

Please think about fixing this in the library and only target standard JAX-RS 2 API, as this would be the most straight forward solution and should be really doable (I can support the effort...), as bending widlfly or EAR deployments is really a hassle I want to avoid.

related Stackoverflow Thread

[grexe]

To be more concrete, this would still require minimal client implementation as Java does not provide a default implementation for JAX-RS 2, sadly. Ideally, a small and lightweight library with no side-effects, but enough options for customization (providers, encoders, decoders etc.) and dependencies should be used.

I am currently evaluating:

• UniREST
  • very nice API, but may require more work to migrate from current Jersey code
• Feign:
  • looks good so far, no external dependencies, only the ones you need and configure (for encoders/decoders, loggers,...),
  • fully JAX-RS compatible if needed (but only version 1.1 of the spec...)

Update: too much effort, the way to go seems to rely on the client configuration returned by the JAX-RS API's ClientBuilder, as in the Oracle JDK JAX-RS docs, see also RESTeasy example - have to dig out the current non-beta version.
This should return a REST provider implementation from the classpath, so users of the docker lib can provide whatever they want, as long as the implementation is JAX-RS 2 compliant.

[grexe]

Sadly it doesn't quite work like that, as you always need a specific implementation included in the project.
I will therefore create a fork with RESTeasy, but not use any provider specific extensions.
Then I'd only need to modify the POM and provide a variant for RESTeasy using a classifier, much like the shaded variant.

[mattnworb]

I have been thinking about attempting to change the library to use a non-Jersey library, since Jersey drags in so so many dependencies and causes headaches for people that use different versions (or at least add an option or alternate DockerClient). For example something like Apache HttpClient or OkHttp.

If you have an environment that uses some other Jersey implementation and docker-client used something non-Jersey, would that also alleviate the issue?

[grexe]

sorry missed your comment/update @mattnworb - yes, you cannot mix different REST implementations, so when Docker uses a specific client library, it will always clash with other implementations. Considering the widespread use of Wildfly in JEE land, this is really a huge problem.

I'm currently working on updating the old commit by @jwgmeligmeyling, stripping Jersey/RESTeasy special code and replacing it with REST-impl-agnostic code from Apache HttpClient.

When I'm done, I'll be happy to provide a pull request, but sadly had no time last week, will revisit this week as it's anyway needed for my work.

[jskjons]

I implemented a simple factory that made it easy to exclude the jersey dependencies in this PR: #340. The alternate proposal to no longer use jersey would also work.

[grexe]

Thanks @jskjons this would also be a promising route to go.
I am actually pretty far with the clean-room JAX-RS 2.0 approach, but hit a snag:
There is no support for custom protocols like unix:// (used for socket connection) in the JAX-RS 2.0 client API, so for that you'd still need Jersey or RESTeasy, below for Jersey:
https://jersey.java.net/documentation/latest/client.html#d0e4844

Also, timeout parameters are not standardized and also implementation dependent.

Maybe we can merge our work @jskjons ?
I'll push my changes to my fork for review, I'm up to date with master.

[grexe]

I've finally come back to this issue and was able to update your PR #340 @jskjons - many thanks for the excellent work!

Only had to fix some dependency issues with jersey pulling in an outdated hk2 lib and some conflicting libs in my own project, but the main issue that kept me busy was a conflict between docker-client's httpclient library and the one seen on Wildfly's classpath.
In the end, a clean manifest entry in the EAR plugin to define a module dependency to httpclient was all it needed, always easy in hindsight,-)

Last issue was that when pulling an image, it is downloaded completely and verified OK but then I still got an IOException, which I fixed by updating the Jackson version to latest 2.8.6 (matching RESTeasy 3.1.1.Final).

Remaining open issue is related to Tests covering Docker swam, all related tests fail with this error using ResteasyClientFactory:

javax.ws.rs.NotAcceptableException: HTTP 406 Not Acceptable
This node is not a swarm manager. Use \"docker swarm init\" or \"docker swarm join\" to connect this node to swarm and try again.

[grexe]

created PR #691 based on my work on PR #340 - please have a look (already needs merging again...:-/ )

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.