Upgrade Java driver for Cassandra to latest version

[maximevw]

This allows a full support of Cassandra 5 without errors/warnings. Indeed, as explained in the discussion #7786, the Cassandra module is still using the deprecated version 3.x of the Java driver for Cassandra. Even if it works with Cassandra 5, it may lead to warnings/errors when using specific features of Cassandra 5. By upgrading the driver to the latest version, we remain compatible with all versions of Cassandra from 3 to 5 (note that version 3 is now reaching EoL).

I successfully tested a locally built version of the Cassandra module including the submitted changes in the tests of Cassandra JDBC wrapper without impact on the performance of the tests running testcontainers with Cassandra.

Few notes regarding the submitted changes:

• In Java driver 4.x, JMX is not supported by default, contrary to the version 3.x, so I removed the method withJmxReporting(boolean).
• To keep good performance when running initialisation script, some specific configuration need to be defined regarding the "debouncing" feature introduced by the Java driver 4.x. This is explained in details in the code.

[eddumelendez]

Hi @maximevw, thanks for submitting a PR and sorry for missing the discussion 😢 Currently, the CassandraContainer implementation relies on the Java client and that's something we are trying to avoid. Do you know if there is a way to execute scripts without using the Java Client? If so, I would propose adding a new implementation under org.testcontainers.cassandra.CassadraContainer that is free of Cassandra Java Driver and can run successfully with latest versions, would be great if works with versions since Cassandra 3. Of course, we will be deprecating org.testcontainers.container.CassandraContainer.

[maximevw]

Hello @eddumelendez, thanks for your response.

Yes, it should be possible to run CQL scripts without using the Java driver thanks to cqlsh CLI provided with Cassandra server. And this should work with Cassandra 3+.

So, executing a cqlsh command at the container startup could be a solution to get rid of the Java driver dependency.

[kiview]

So, executing a cqlsh command at the container startup could be a solution to get rid of the Java driver dependency.

@maximevw Sounds like a great suggestion, do you want to have a stab at this approach?

@eddumelendez What is the motivation behind doing this in a new version, rather than in the old version? It is not really a breaking change, is it?

[maximevw]

@kiview Sure, I'll take a look at this asap.

[eddumelendez]

What is the motivation behind doing this in a new version, rather than in the old version? It is not really a breaking change, is it?

Current CassandraContainer implementation relies on Cluster class from cassandra java driver. So, the dependency could not be removed at all without causing breaking changes.

[kiview]

After discussing more with @eddumelendez, it seems indeed a good idea to deprecate org.testcontainers.container.CassandraContainer and do the proposed changes in a new class org.testcontainers.cassandra.CassadraContainer, so we can get our modules slowly ready for JPMS without suffering from split-package issues.

[maximevw]

Hello @kiview @eddumelendez,

As previously discussed, I updated this pull request to implement org.testcontainers.cassandra.CassandraContainer using cqlsh command instead of the Java driver to run script.
I also deprecated classes in org.testcontainers.containers package.

I let you review the changes.

[eddumelendez]

Thanks for the quick update, @maximevw ! Can you please run ./gradlew spotlessApply for code formatting, please?

[maximevw]

Sure @eddumelendez!
Done and pushed 🙂

[eddumelendez]

Thanks for your contribution! Existing implementation shouldn't be touched to support Cassandra 5. That's why the new implementation is added. The new implementation solved two issues:

• implementation doesn't rely on cassandra driver
• transitive dependency to cassandra driver could be removed

[maximevw]

Thanks for your contribution! Existing implementation shouldn't be touched to support Cassandra 5. That's why the new implementation is added. The new implementation solved two issues:

• implementation doesn't rely on cassandra driver
• transitive dependency to cassandra driver could be removed

@eddumelendez I pushed the changes following your review.

[eddumelendez]

Small comments. Will perform a deep review later today.

[maximevw]

@eddumelendez Changes done :)