Provide an API to customize Netty channel initialization
Description
Environment
Pull Requests
Attachments
Activity
Olivier Michallat February 27, 2015 at 11:26 PM
PipelineCustomizer can be extended to also cover JAVA-676.
Olivier Michallat February 27, 2015 at 10:05 PM(edited)
I can confirm that the shaded JAR can be published as a separate artifact: I've made the required configuration changes in #281, which will be merged soon.
This will allow us to provide:
a standard (non-shaded) version. People who want to use
PipelineCustomizerwill have to use this one.a shaded version that does not depend on Netty.
PipelineCustomizerwill still be here, but it will reference shaded Netty classes with a rewritten package name.
Olivier Michallat February 16, 2015 at 7:14 PM
So would have to be reverted too.
The Shade plugin has an option to keep the normal JAR and publish the shaded one with a different artifactId (e.g. cassandra-driver-core-shaded), that would solve the problem. We'll still need some Maven voodoo to fix the OSGI stuff in the shaded JAR and not in the un-shaded one (see JAVA-620) but that should be doable (at worst, generate the shaded JAR from a separate module).
Sylvain Lebresne February 4, 2015 at 1:56 PM
I was initially thinking of adding just 2 methods to SocketOptions:
but that only works for stateless/sharable handlers so Olivier's interface is probably a better idea (slightly bother me to have to add an interface for this, but I guess that's not a huge deal).
So would have to be reverted too.
Which is annoying.
Olivier Michallat February 4, 2015 at 1:18 PM
We could expose the following interface and allow its injection at configuration time (naming is tentative):
As Sylvain noted, this will leak Netty to the public API. Given the requirement, I don't think we can avoid it. So would have to be reverted too.
Final fix:
NettyOptions allows custom Netty configuration.
Initial issue description:
We are implementing security between java-driver Client and Cassandra using own own connection called RadConnection. RadConnection requires a special way to create the org.jboss.netty.channel.Channel. So instead of using the com.datastax.driver.core.Connection we would be using com.xxx.RadConnection.
com.datastax.driver.core.Connection has lot of logic apart from just creating the Channel that we want to reuse. Ideally we would subclass from c.d.d.c.Connection and over ride the constructor to create the channel in our specific way. However c.d.d.c.Connection is currently not public and we will have to resort to ugly ways of creating RadConnection in a fake package com.datastax.driver.core just so we can access Connection.
Also the com.datastax.driver.core.Cluster.Manager#Manager hard codes the connection factory.
this.connectionFactory = new Connection.Factory(this, configuration);
We need to over ride Cluster.Manager.connectionFactory with a RadConnection.Factory that is capable of creating RadConnections.
Again Connection.Factory has useful functionality that we want to inherit from and simply override the method
public Connection open(Host host)
I think in order to achieve what we want to do, the following things need to be done at the Driver layer.
1. Make ConnectionFactory pluggable through Cluster.Builder
2. Make c.d.d.c.Connection public
3. Make all the private variable/methods in c.d.d.c.Connection protected so RadConnection can use them
I have attached some prototype code that shows how a RadConnection would look like.
What do you think about this? Are there other/better ways to plugin Connectin.Factory?