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