hk2/jersey crashing on Spring boot 2.0 w/ Java 9

[MrPlow442]

BUG REPORT:

Description

docker-client does not work at all on Spring boot 2.0 + Java 9 combo. Causes one of two possible exceptions depending on which dependencies are added

How to reproduce

• Create a Spring Boot 2.0 project with reactive-web dependency.
• Add docker-client dependency (tested with currently latest available version on maven: 8.11.4)
• Add DefaultDockerClient.fromEnv().build() to the default generated test
• Run the test

What do you expect

docker client is initialized and no exceptions are thrown

What happened instead

java.lang.NoClassDefFoundError: org/glassfish/hk2/api/MultiException is thrown immediately.

If hk2 dependency is explicitly added to maven then java.lang.IllegalStateException: InjectionManagerFactory not found. is thrown instead

Software:

• docker version: Client:
  Version: 17.11.0-ce
  API version: 1.34
  Go version: go1.9.2
  Git commit: 1caf76ce6b
  Built: Sun Dec 10 10:15:57 2017
  OS/Arch: linux/amd64

Server:
Version: 17.11.0-ce
API version: 1.34 (minimum version 1.12)
Go version: go1.9.2
Git commit: 1caf76ce6b
Built: Sun Dec 10 10:16:13 2017
OS/Arch: linux/amd64
Experimental: false

• Spotify's docker-client version: 8.11.4

Full backtrace

java.lang.NoClassDefFoundError: org/glassfish/hk2/api/MultiException

	at com.example.dockerclienttest.DockerclienttestApplicationTests.contextLoads(DockerclienttestApplicationTests.java:17)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.springframework.test.context.junit4.statements.RunBeforeTestExecutionCallbacks.evaluate(RunBeforeTestExecutionCallbacks.java:73)
	at org.springframework.test.context.junit4.statements.RunAfterTestExecutionCallbacks.evaluate(RunAfterTestExecutionCallbacks.java:83)
	at org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(RunBeforeTestMethodCallbacks.java:75)
	at org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate(RunAfterTestMethodCallbacks.java:86)
	at org.springframework.test.context.junit4.statements.SpringRepeat.evaluate(SpringRepeat.java:84)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
	at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:251)
	at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:97)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
	at org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
	at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:70)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:190)
	at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
	at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
	at com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
	at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
	at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
Caused by: java.lang.ClassNotFoundException: org.glassfish.hk2.api.MultiException
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:582)
	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:185)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:496)
	... 31 more

[manish-panwar]

I am having same error but with Java 8 and Spring-boot 2.x. Later I downgraded Spring-boot version to 1.5.x and still same problem - Not sure what I am doing wrong.

[Galorhallen]

I had the same issue with Java 8 and spring-boot 2.x. Rolling back to spring-boot 1.5 solved the issue

[tdomzal]

I had similar problem in testing library which depends on spotify docker client 8.9.2. - it seems to be related to changes in jersey client 2.26.
Workaround described here helped:
tdomzal/junit-docker-rule#42 (comment)

[matzegebbe]

@tdomzal
Thanks! The workaround works with 2.0

        <dependency>
            <groupId>org.glassfish.jersey.inject</groupId>
            <artifactId>jersey-hk2</artifactId>
            <version>2.26</version>
        </dependency>
        <dependency>
            <groupId>org.glassfish.jersey.bundles.repackaged</groupId>
            <artifactId>jersey-guava</artifactId>
            <version>2.25.1</version>
        </dependency>

[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.

[juwit]

I've had exactly the same issue with spring-boot 2.1.

I applied @matzegebbe 's workaround with the current jersey version, and without guava :

<dependency>
  <groupId>org.glassfish.jersey.inject</groupId>
  <artifactId>jersey-hk2</artifactId>
  <version>2.27</version>
</dependency>