Github user vrozov commented on a diff in the pull request: https://github.com/apache/drill/pull/991#discussion_r144697258 --- Diff: exec/java-exec/pom.xml --- @@ -701,18 +707,21 @@ <!-- Include the os-maven-plugin to get os.detected.classifier --> - <extension> - <groupId>kr.motd.maven</groupId> - <artifactId>os-maven-plugin</artifactId> - <version>1.5.0.Final</version> - </extension> - </extensions> + <!-- Uncomment the following to get a debug build that allows openssl support --> --- End diff -- Looking at netty code it seems to use `Class.forName("io.netty.internal.tcnative.SSL", false, OpenSsl.class.getClassLoader());` ([see OpenSsl](https://github.com/netty/netty/blob/4.1/handler/src/main/java/io/netty/handler/ssl/OpenSsl.java)), so if all netty-tcnative OS dependent jars are on the classpath, it should load the first in the classpath (if delegated to the system classloader) or one that OpenSsl classloader finds. My understanding is that OpenSsl class is loaded by the system classloader (I may be wrong), but in this case, having all variants of netty-tcnative on the classpath, will not resolve the issue as netty will try to load "io.netty.internal.tcnative.SSL" class only from one of the jars and if it happens to be a wrong jar, will disable OpenSsl functionality.
---