CqlSessionFactoryBean implements PersistenceExceptionTranslator that leads to be instantiated by PersistenceExceptionTranslationInterceptor on every RuntimeException from a repository

[vladtf]

org.springframework.data.cassandra.config.CqlSessionFactoryBean implements PersistenceExceptionTranslator that means that on each RuntimeException PersistenceExceptionTranslationInterceptor will find the bean for class CqlSessionFactoryBean to try translate the exception. If Cassandra is not available getBean method will fail with BeanCreationException because CqlSessionFactoryBean tried to connect to Cassandra and failed.

Expected behavior is that Spring will find a bean for class org.springframework.data.cassandra.core.cql.CassandraExceptionTranslator and try to translate RuntimeException using this bean, instead of trying to create a new object of CqlSessionFactoryBean.

A possible solution is to remove implements PersistenceExceptionTranslator from CqlSessionFactoryBean.

[mp911de]

This arrangement is in place since the inception of the Cassandra module. Using CqlSessionFactoryBean requires Cassandra connectivity and generally in Spring Data, exception translation is coupled to the factory bean that creates the client. Since Cassandra Driver 4, driver objects cannot be created any longer without Cassandra connectivity.

[vladtf]

The thing is that I'm also using an ldap database. There is a flow when Cassandra is down, I search in ldap using spring repository, search fails because of no such object and it tries to translate ldap exception. When translating, it finds cassandra translator which is CqlSessionFactoryBean and when calling getBean of cqlSession it throws an BeanCreationException because it tried to connect to Cassandra.

[vladtf]

As a workaround I added in jar an implementation that removes implementation of PersistenceExceptionTranslator from CqlSessionFactoryBean and registered a bean of class CassandraExceptionTranslator separately.