gRPC+SSL+uber jar+Linux=无法加载netty tcnative

Question

感谢gRPC+SSL上的@nmittler=不满意的链接错误我已经在我的Windows PC和目标Linux平台上运行了gRPC+SSSL。

但仅当我为io.netty/netty-tcnative-boringssl-static/1.1.33.Fork17依赖项指定<classifier>时。可以是：

1. 硬编码(例如到windows-x86_64)
2. 使用os-maven插件和${os.detected.classifier}注入

但这意味着我只能运行：

1. Windows(或我硬编码的任何平台)
2. 我用来编译的平台

但我真正想做的是在Windows上编译，但在Linux上运行。因此，在理论上，我可以不使用<classifier>来引入uber jar(如文档中所述)。

但这不起作用：当我穿过io.netty.util.internal.NativeLibraryLoader.load()时，我发现有一个对System.mapLibraryName()的调用。

• 在Windows上，这将正确返回netty-tcnative.dll
• 但在Linux(RHEL7)上，它返回libnetty-tcnative.so。。。它不在uber jar中(jar tf netty-tcnative-boringssl-static-1.1.33.Fork17.jar返回META-INF/native/libnetty-tcnative-linux-x86_64.so等)

查看分类的linux版本的jar，我可以看到它包含META-INF/native/libnetty-tcnative.so。。。这意味着要么uber jar需要以不同的方式构建(将libnetty-tcnative-linux-x86_64.so重命名为libnetty-tcnative.so)，要么NativeLibraryLoader需要考虑不同的命名。。。

我走对了吗？有人能帮忙解决这个问题吗？

Answer 1

没错，Maven Central上的uber jar不包含共享库。目前还不清楚问题是构建还是部署jar。我养大了https://github.com/netty/netty-tcnative/issues/145以跟踪修复。

Answer 2

升级到io.grpc/grpc-all/0.14.0(从0.13.2)解决了我的问题，因为它带来了io.netty/netty-handler的更新版本(4.1.0.CR7与4.1.0.CR3)。