Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Drop use of specific REST client implementation #161

Closed
dmandalidis opened this issue Apr 2, 2020 · 0 comments
Closed

Drop use of specific REST client implementation #161

dmandalidis opened this issue Apr 2, 2020 · 0 comments

Comments

@dmandalidis
Copy link
Owner

dmandalidis commented Apr 2, 2020 •
edited

docker-client currently pulls Jersey client for performing the REST calls to a Docker engine. This is not actually right since it also manages pooling semantics which is a consumer's responsibility. Moreover, when docker-client is pulled in projects where a non-Jersey REST client exists (e.g. resteasy), clients projects are ending up having two implementations of the JAX-RS client API and this is certainly a problem in flat-classpath applications.

So, effort should be spent so as to make docker-client agnostic so that client projects can use their own javax.ws.rs.client.Client implementation. There are two ways forward to solve this problem:

  • (medium impact) Either drop completely Jersey dependencies and allow client projects to pass an already-constructed javax.ws.rs.client.Client implementation or

  • (minimum impact) Extract DefaultDockerClient$Builder to JerseyDockerClientBuilder (or something similar) and switch the Jersey dependencies to <optiona>true</optional> and let consumer projects use this builder or an alternative of their choice.

edit: JavaEE not a problem, flat-classpath is
dmandalidis added a commit that referenced this issue Apr 18, 2020
@dmandalidis
Rationalize DefaultDockerClient and Builder responsibities (fixes #161,
4138689 
#91)

- Force use of Builder to create a Docker Client
- Explicitly pull JAXRS API dependency
- Pull out inner DockerClient builder to JerseyDockerClientBuilder
- Setup builder inheritance so that a custom JAXRS client can be plugged
- Switch Jersey dependencies to optional
- Remove testing of notimeout methods
dmandalidis added a commit that referenced this issue Apr 18, 2020
@dmandalidis
Rationalize DefaultDockerClient and Builder responsibities (fixes #161,
fcdfd83 
#91)

- Force use of Builder to create a Docker Client
- Explicitly pull JAXRS API dependency
- Pull out inner DockerClient builder to JerseyDockerClientBuilder
- Setup builder inheritance so that a custom JAXRS client can be plugged
- Switch Jersey dependencies to optional
- Remove testing of notimeout methods
dmandalidis added a commit that referenced this issue Apr 18, 2020
@dmandalidis
Rationalize DefaultDockerClient and Builder responsibities (fixes #161,
e8e1032 
#91)

- Force use of Builder to create a Docker Client
- Explicitly pull JAXRS API dependency
- Pull out inner DockerClient builder to JerseyDockerClientBuilder
- Setup builder inheritance so that a custom JAXRS client can be plugged
- Switch Jersey dependencies to optional
- Remove testing of notimeout methods
This was referenced May 13, 2020
Closed
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@dmandalidis