testcontainers-java: Shading of Netty breaks on Linux because of native bindings

The shading does not work for Linux due to native libraries for custom epoll transport not being shaded.

The problem is being described here: https://github.com/netty/netty/pull/4820

The following stack-trace shows the issue:

java.lang.NoClassDefFoundError: io/netty/channel/epoll/NativeStaticallyReferencedJniMethods

    at java.lang.ClassLoader$NativeLibrary.load(Native Method)
    at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1941)
    at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1824)
    at java.lang.Runtime.load0(Runtime.java:809)
    at java.lang.System.load(System.java:1086)
    at org.testcontainers.shaded.io.netty.util.internal.NativeLibraryLoader.load(NativeLibraryLoader.java:193)
    at org.testcontainers.shaded.io.netty.channel.epoll.Native.<clinit>(Native.java:60)
    at org.testcontainers.shaded.io.netty.channel.epoll.IovArray.<clinit>(IovArray.java:57)
    at org.testcontainers.shaded.io.netty.channel.epoll.EpollEventLoop.<init>(EpollEventLoop.java:57)
    at org.testcontainers.shaded.io.netty.channel.epoll.EpollEventLoopGroup.newChild(EpollEventLoopGroup.java:78)
    at org.testcontainers.shaded.io.netty.channel.epoll.EpollEventLoopGroup.newChild(EpollEventLoopGroup.java:30)
    at org.testcontainers.shaded.io.netty.util.concurrent.MultithreadEventExecutorGroup.<init>(MultithreadEventExecutorGroup.java:77)
    at org.testcontainers.shaded.io.netty.util.concurrent.MultithreadEventExecutorGroup.<init>(MultithreadEventExecutorGroup.java:48)
    at org.testcontainers.shaded.io.netty.channel.MultithreadEventLoopGroup.<init>(MultithreadEventLoopGroup.java:57)
    at org.testcontainers.shaded.io.netty.channel.epoll.EpollEventLoopGroup.<init>(EpollEventLoopGroup.java:63)
    at org.testcontainers.shaded.io.netty.channel.epoll.EpollEventLoopGroup.<init>(EpollEventLoopGroup.java:51)
    at org.testcontainers.shaded.com.github.dockerjava.netty.DockerCmdExecFactoryImpl$UnixDomainSocketInitializer.init(DockerCmdExecFactoryImpl.java:221)
    at org.testcontainers.shaded.com.github.dockerjava.netty.DockerCmdExecFactoryImpl.init(DockerCmdExecFactoryImpl.java:197)
    at org.testcontainers.shaded.com.github.dockerjava.core.DockerClientImpl.withDockerCmdExecFactory(DockerClientImpl.java:159)
    at org.testcontainers.shaded.com.github.dockerjava.core.DockerClientBuilder.build(DockerClientBuilder.java:45)
    at org.testcontainers.dockerclient.DockerClientProviderStrategy.getClientForConfig(DockerClientProviderStrategy.java:103)
    at org.testcontainers.dockerclient.EnvironmentAndSystemPropertyClientProviderStrategy.test(EnvironmentAndSystemPropertyClientProviderStrategy.java:18)
    at org.testcontainers.dockerclient.DockerClientProviderStrategy.getFirstValidStrategy(DockerClientProviderStrategy.java:54)
    at org.testcontainers.DockerClientFactory.client(DockerClientFactory.java:82)
    at org.testcontainers.DockerClientFactory.client(DockerClientFactory.java:70)
    at org.testcontainers.containers.GenericContainer.<init>(GenericContainer.java:105)
    at org.testcontainers.containers.FixedHostPortGenericContainer.<init>(FixedHostPortGenericContainer.java:16)

About this issue

Original URL
State: closed
Created 8 years ago
Comments: 19 (13 by maintainers)

Commits related to this issue

Change location of system property setting to ensure that netty relocated package name is available for DockerCompose usage scenarios. Fixes #178 — committed to testcontainers/testcontainers-java by rnorth 8 years ago
Change location of system property setting to ensure that netty relocated package name is available for DockerCompose usage scenarios. Fixes #178 — committed to testcontainers/testcontainers-java by rnorth 8 years ago

Most upvoted comments

Ah, this makes sense if going via DockerComposeContainer. This stopped subclassing GenericContainer in the 1.1.0 release, so it seems probable that the route to obtaining a DockerClient instance is not initialising the GenericContainer class.

I think the System.setProperty(...) static call should probably be transplanted over to DockerClientFactory, which is the common element in the path to obtaining the client instance.

rnorth on Jul 26, 2016