-
-
Notifications
You must be signed in to change notification settings - Fork 15.9k
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
NoSuchMethodError newSSL when running under tomcat #5648
Comments
what version of netty-tcnative are you using? |
I'm not using netty-tcnative. It is finding the |
A few more observations:
I think I can explicitly include |
we plan to put netty-tcnative into different package/namespace and I expect the problem should be resolved at that point. |
I looked at it some more to get a better idea of what it was doing. The problem seems to be from 379ad2c. The load is failing, but it looks like what tomcat is providing causes the initialize to succeed. So it is getting by the checks and then failing with a NoSuchMethodError on Changing the package would work for my use-case. However, reading through netty/netty-tcnative#136 it seems there are some additional complications for users that need tcnative. For my immediate use-case I was also able to get it to work by adding an additional sanity check: diff --git a/handler/src/main/java/io/netty/handler/ssl/OpenSsl.java b/handler/src/main/java/io/netty/handler/ssl/OpenSsl.java
index a151670..14ea5d9 100644
--- a/handler/src/main/java/io/netty/handler/ssl/OpenSsl.java
+++ b/handler/src/main/java/io/netty/handler/ssl/OpenSsl.java
@@ -78,12 +78,18 @@ public final class OpenSsl {
// Test if netty-tcnative is in the classpath first.
try {
- Class.forName("org.apache.tomcat.jni.SSL", false, OpenSsl.class.getClassLoader());
+ Class<?> cls = Class.forName("org.apache.tomcat.jni.SSL", false, OpenSsl.class.getClassLoader());
+ cls.getMethod("newSSL", long.class, boolean.class);
} catch (ClassNotFoundException t) {
cause = t;
logger.debug(
"netty-tcnative not in the classpath; " +
OpenSslEngine.class.getSimpleName() + " will be unavailable.");
+ } catch (NoSuchMethodException t) {
+ cause = t;
+ logger.debug(
+ "incompatible org.apache.tomcat.jni.SSL in the classpath; " +
+ OpenSslEngine.class.getSimpleName() + " will be unavailable.");
}
// If in the classpath, try to load the native library and initialize netty-tcnative. Is there any ETA on the package name change? Is it worthwhile sending a PR for the workaround above in the mean time? |
No eta and yes a pr would be awesome
|
@brharrington Let me just take care of it for you... Thanks for the tip! |
@brharrington or if you like you can also submit the PR for fame an profit ;) Just let me know what you prefer. |
Also I think this will most likely not work with later versions of tomcat as they added the same method: Let me think about a better way to work around it. |
@brharrington ok I think I have an idea... stay tuned |
Motivation: If netty is used in a tomcat container tomcat itself may ship tcnative. Because of this we will try to use OpenSsl in netty and fail because it is different to netty-tcnative. Modifications: Ensure if we find tcnative it is really netty-tcnative before using it. Result: No more problems when using netty in a tomcat container that also has tcnative installed.
Motivation: If netty is used in a tomcat container tomcat itself may ship tcnative. Because of this we will try to use OpenSsl in netty and fail because it is different to netty-tcnative. Modifications: Ensure if we find tcnative it is really netty-tcnative before using it. Result: No more problems when using netty in a tomcat container that also has tcnative installed.
Motivation: If netty is used in a tomcat container tomcat itself may ship tcnative. Because of this we will try to use OpenSsl in netty and fail because it is different to netty-tcnative. Modifications: Ensure if we find tcnative it is really netty-tcnative before using it. Result: No more problems when using netty in a tomcat container that also has tcnative installed.
Motivation: If netty is used in a tomcat container tomcat itself may ship tcnative. Because of this we will try to use OpenSsl in netty and fail because it is different to netty-tcnative. Modifications: Ensure if we find tcnative it is really netty-tcnative before using it. Result: No more problems when using netty in a tomcat container that also has tcnative installed.
Work around by #5666 |
Great, thanks for the quick turn around. |
any ETA on the next 4.1.x release with this fix? We have a couple apps that we would like to upgrade from Netty 4.1.0.Beta8 to 4.1.x.Final once this fix is released. |
Next week
|
sounds good. thanks ! |
Motivation: If netty is used in a tomcat container tomcat itself may ship tcnative. Because of this we will try to use OpenSsl in netty and fail because it is different to netty-tcnative. Modifications: Ensure if we find tcnative it is really netty-tcnative before using it. Result: No more problems when using netty in a tomcat container that also has tcnative installed.
Motivation: If netty is used in a tomcat container tomcat itself may ship tcnative. Because of this we will try to use OpenSsl in netty and fail because it is different to netty-tcnative. Modifications: Ensure if we find tcnative it is really netty-tcnative before using it. Result: No more problems when using netty in a tomcat container that also has tcnative installed.
This might be related to #5423 or #5539, but it isn't clear to me if either of those are the same issue. We have an application with a netty client running under tomcat (7.0.59) and tomcat is using the tomcat native listener:
This was working fine with netty-4.1.0.Beta8. When trying to update to 4.1.3.Final we started getting a failure for the netty client when trying to hit an SSL endpoint:
That method doesn't exist in the tomcat-native version that comes with tomcat until version 1.2 and we have 1.1.32. When running with 4.1.0.Beta8, it failed to use openssl and would fall back to the default implementation:
The text was updated successfully, but these errors were encountered: