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.

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

classes conflict when using docker-java for production code #2860

Closed
juwit opened this issue Jun 12, 2020 · 3 comments
Closed

classes conflict when using docker-java for production code #2860

juwit opened this issue Jun 12, 2020 · 3 comments

Comments

@juwit
Copy link

juwit commented Jun 12, 2020

Hi there !

First, thank you for the great work. I use testcontainers since a few months, and it's great !

I have an issue in one of my app using :

  • docker-java 3.2.2 for production code, with transport-zerodep
  • testcontainers 1.14.3 for integration testing

This kind of code raises a NoSuchMethodError when executed in an integration test :

@Bean
DockerClient client(DockerClientConfig config, DockerHttpClient transport){
    return DockerClientImpl.getInstance(config, transport);
}
Caused by: java.lang.NoSuchMethodError: com.github.dockerjava.core.DockerClientImpl.getInstance(Lcom/github/dockerjava/core/DockerClientConfig;Lcom/github/dockerjava/transport/DockerHttpClient;)Lcom/github/dockerjava/api/DockerClient;

When digging a little, I found out that test containers embeds docker-java 3.2.0, and the classes are not shaded. So It conflicts with my production code using docker-java 3.2.2.
It seems that this getInstance method was added in docker-java 3.2.2 (others are deprecated).

As a workaround, I stick with docker-java 3.2.0, and a transport-okhttp for now, but still, this issue could help someone else :)

@bsideup
Copy link
Member

bsideup commented Jun 12, 2020

Hi @juwit,

First of all, thanks for upgrading to the latest version of docker-java and especially for trying the zerodep (aka Apache HttpClient5) transport! :)

There is indeed an issue when both libraries are used. The history of it is full of hard decisions, where docker-java's set of dependencies was so hard to have that we decided to re-shade it and include into Testcontainers' jar.

The good news is that we worked with the docker-java team and extracted the API module, so the next release of Testcontainers will finally stop including docker-java-api classes 🎉

Expect it (1.15.0 release) to happen soon, and I hope the workaround worked fine for now.
Actually, I think you can even use 3.2.2, but, instead of calling getInstance(config, transport), you can replace it with getInstance(config).withDockerCmdExecFactory(new OkHttpDockerCmdExecFactory()), or even zerodep + DefaultDockerCmdExecFactory. These are deprecated but fully working methods (disclaimer: I am the current maintainer of docker-java)

@juwit
Copy link
Author

juwit commented Jun 13, 2020

Hi @bsideup

Thank you for your reply.

I upgraded to docker-java 3.2.2, and used okhttp-transport with this snippet :

@Bean
DockerClient client(DockerClientConfig config){
    return DockerClientImpl.getInstance(config)
        .withDockerCmdExecFactory(new OkHttpDockerCmdExecFactory());
}

I'll wait for the testcontainers 1.15 release to switch to the zerodep transport (couldn't make it work)

You're doing great work with docker-java, I may open a few issues, or maybe contribute to it if I can find the time to do so.

@bsideup
Copy link
Member

bsideup commented Jun 16, 2020

@juwit thanks for your kind feedback :)

FYI I just submitted #2882 for that.

I will close this issue since it is a duplicate of #1113

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants