NIFI-15254 Add Cassandra Processors into NiFi 2.x Version.

[vishal-firgan-ksolves]

Summary

This PR introduces Cassandra processor support for Apache NiFi 2.x, enabling Cassandra integration aligned with the latest DataStax Java driver.

NIFI-15254

Enhancements over NiFi 1.28:

• NiFi 1.28 Cassandra processor did not support the following column types: UUID, TIMEUUID, DATE, TIME, TIMESTAMP, DECIMAL, VARINT, etc.
• This processor adds proper type conversions for these and other relevant types according to Cassandra column definitions.

Tracking

Please complete the following tracking steps prior to pull request creation.

Issue Tracking

• Apache NiFi Jira issue created

Pull Request Tracking

• Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-00000
• Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000
• Pull request contains commits signed with a registered key indicating Verified status

Pull Request Formatting

• Pull Request based on current revision of the main branch
• Pull Request refers to a feature branch with one commit containing changes

Verification

Please indicate the verification steps performed prior to pull request creation.

Build

• Build completed using ./mvnw clean install -P contrib-check
  • JDK 21
  • JDK 25

Licensing

• New dependencies are compatible with the Apache License 2.0 according to the License Policy
• New dependencies are documented in applicable LICENSE and NOTICE files

Documentation

• Documentation formatting appears as expected in rendered files

[exceptionfactory]

Thanks for putting together this updated version of Cassandra components @vishal-firgan-ksolves.

It is great to have the upgrade to the latest client driver version included.

A recent attempt to reintroduce Cassandra support stalled, but includes some important feedback about additional changes needed. In particular, a number of important implementation conventions need to be addressed before this can be considered for inclusion. I have not reviewed this code in detail, but it looks like most of the following issues mentioned in this comment also need to be addressed in this pull request:

#10006 (review)

If you are willing to put in the time to work through these issues, then this has the opportunity go forward.

[exceptionfactory]

Also for the purpose of efficient review, I recommend breaking this pull request into multiple parts. Specifically, starting with only the QueryCassandra Processor would allow us to get the core interface and conventional details addressed. Once that is reviewed and merged, the PutCassandra Processors could be considered. This is not a hard requirement, but it more components will require more review time.

[vishal-firgan-ksolves]

Thank you for the feedback @exceptionfactory and for pointing me to the relevant review. I will work through these suggestions and update the code to align with NiFi’s current conventions. I'll let you know once the changes are ready for another look.

[vishal-firgan-ksolves]

@exceptionfactory I’ve pushed a new commit that takes care of all the review and convention updates. Since the processors share a common abstract base class and a few tests are used across multiple processors, splitting the PR right now would likely create duplication and inconsistencies.
Would it be okay to keep this as a single PR for now?

[vishal-firgan-ksolves]

Hii @exceptionfactory , I'm just following up to see if you've had a moment to look at the latest commits. I've finished the requested convention updates and addressed the previous feedback. Looking forward to your thoughts when you have a chance! Thanks!

[exceptionfactory]

Thanks for the updates @vishal-firgan-ksolves, I will look to review this again soon.

[vishal-firgan-ksolves]

Hi @exceptionfactory
I just wanted to follow up on this PR since it has been a few weeks. Whenever you have time, I would really appreciate another review.
Please let me know if there’s anything further needed from my side to help move this forward.

[exceptionfactory]

@vishal-firgan-ksolves On a very quick review, I noticed some implementation issues with error handling and logging, along with some dependency management concerns where specific versions are being used instead of inheriting configuration values. There are also a number of structural questions in terms of the abstract classes versus the concrete implementations, and it is not quite clear that all of the previous Processors should remain supported.

With that background, I'm not able to provide the kind of detailed review necessary right now for the volume and variety of components in the current pull request. As mentioned previously, the best possibility for moving this forward would be to reduce the scope significantly. Rather than attempting to add back all of the previous Processors, I recommend selecting one or two as the initial candidates. That would provide the opportunity to reconsider the surface of the of the Controller Service interface and its alignment with the referencing Processors.