Provide an API to customize Netty channel initialization


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 So instead of using the com.datastax.driver.core.Connection we would be using

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?



Pull Requests



Olivier Michallat
February 4, 2015, 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.

Sylvain Lebresne
February 4, 2015, 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 16, 2015, 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).

Olivier Michallat
February 27, 2015, 10:05 PM

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 PipelineCustomizer will have to use this one.

  • a shaded version that does not depend on Netty. PipelineCustomizer will still be here, but it will reference shaded Netty classes with a rewritten package name.

Olivier Michallat
February 27, 2015, 11:26 PM

PipelineCustomizer can be extended to also cover JAVA-676.



Alexandre Dutra


Vishy Kasar



PM Priority


Affects versions

Fix versions

Pull Request


Doc Impact




External issue ID


External issue ID