-
-
Notifications
You must be signed in to change notification settings - Fork 9
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.
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
Drop use of specific REST client implementation #161
Comments
dmandalidis
added a commit
that referenced
this issue
Apr 18, 2020
#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
#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
#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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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, whendocker-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 ownjavax.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
toJerseyDockerClientBuilder
(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
The text was updated successfully, but these errors were encountered: