ConnectionState.connect() should use generic Grpc.newChannelBuilderForAddress() #249
Comments
|
Hey @coreydowning, I wasn't aware of that. I'll have that patch sorted out as soon as possible |
|
Thank you very much! I sorted out most of it but haven't figured out an alternative to this if (!settings.isTlsVerifyCert())
sslContextBuilder.trustManager(InsecureTrustManagerFactory.INSTANCE); |
|
So far it seems impossible to keep feature parity while being grpc-backend agnostic. I can replicate everything but being able to disable certificate verification, which is quite useful in testing/dev environments. I'm open to suggestion, the related PR is linked to this issue. |
|
I will take a look at this today and see if I can come up with anything. |
|
Good idea to decouple the stuff! The GRPC client currently does not work with Quarkus native (GraalVM) because of multiple problems caused by the grpc-netty-shaded implementation. It would be great if it would be possible to use the Quarkus GRPC client instead. |
|
Any update? |
|
I haven't looked at that PR since my last message. Did |
EventStoreDB-Client Version: 5.1.0
The
ConnectionState.connect(...)method currently creates a managed gRPC channel using theNettyChannelBuilderfromio.grpc:grpc-netty-shaded. We have a project that uses gRPC for multiple things and needs to use theio.grpc:grpc-nettytransport instead of the shaded one. Because the connect method uses the netty shaded channel builder, this is impossible.My suggested change is to move to using one of the flavors of
Grpc.newChannelBuilder()function, allowing gRPC to dynamically choose the correct transport based on what is available on the classpath.The text was updated successfully, but these errors were encountered: