gRPC + SSL + uber jar + Linux = 加载 netty-tcnative 失败

Question

感谢 上的@nmittler 我已经在我的 Windows PC 和目标 Linux 平台上运行了 gRPC + SSL。

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

1. 硬编码（例如 windows-x86_64）
2. 使用 os-maven-plugin 和 ${os.detected.classifier}
注入

但这意味着我只能 运行 on:

1. Windows（或我硬编码的任何平台）
2. 我编译的平台

但我真正希望能够在Windows上编译，但运行在Linux上编译。因此，理论上，我可以不使用 <classifier> 来引入 uber-jar（如 the docs 中指定）。

但这不起作用：当我单步执行 io.netty.util.internal.NativeLibraryLoader.load() 时，我找到了对 System.mapLibraryName().

的调用

• 在 Windows 这个正确 returns netty-tcnative.dll.
• 但是在 Linux (RHEL 7) 上它 returns libnetty-tcnative.so ... 它不在 uber-jar 中 (jar tf netty-tcnative-boringssl-static-1.1.33.Fork17.jar returns , 其中 META-INF/native/libnetty-tcnative-linux-x86_64.so).

查看 jar 的 classified linux 版本我可以看到它包含 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） .