springboot Non-compatible bean instance of type [org.neo4j.ogm.session.SessionFactory] being injected for [org.springframework.data.cassandra.SessionFactory]

I am using both spring-boot-starter-data-cassandra and spring-boot-starter-data-neo4j. Also, I am using multi keyspaces for cassandra so had to overrride AbstractCassandraConfiguration. However, when I am starting application, I get error resolving SessionFactory.

It appears there is a clash of SessionFactory and org.neo4j.ogm.session.SessionFactory is being injected into cassandra.SessionFactory.

Caused by: java.lang.IllegalStateException: @Bean method AbstractCassandraConfiguration.sessionFactory called as bean reference for type [org.springframework.data.cassandra.SessionFactory] but overridden by non-compatible bean instance of type [org.neo4j.ogm.session.SessionFactory]. Overriding bean of same name declared in: class path resource [org/springframework/boot/autoconfigure/data/neo4j/Neo4jDataAutoConfiguration$Neo4jOgmSessionFactoryConfiguration.class]```

**Comment From: nosan**

It is expected behavior, `Neo4jDataAutoConfiguration` creates a bean named sessionFactory and `AbstractCassandraConfiguration` does the same.  
By default, this behavior is forbidden in Spring Boot and you have to set (`spring.main.allow-bean-definition-overriding=true`) 

Currently, you can override the `sessionFactory` method in `AbstractCassandraConfiguration` and rename the bean name with `@Bean` annotation.


```java
@Configuration
public class CassandraConfiguration extends AbstractCassandraConfiguration {


    @Bean("cassandraSessionFactory")
    @Override
    public SessionFactory sessionFactory() {
        return super.sessionFactory();
    }
 //other methods

}

The other way is to create your own Neo4j SessionFactory with a different name.

Comment From: nosan

Maybe it makes sense to rename sessionFactory bean in Neo4jDataAutoConfiguration to neo4jSessionFactory to avoid such collisions.

Comment From: snicoll

Indeed, I don't think it is expected behaviour that such beans collide with each other. This unfortunately happens with such generic names and also a reason why we forbid bean overriding by default as it's easier for folks to report problems like this to us.

Comment From: nosan

I don't think it is expected behaviour that such beans collide with each other

I meant bean-overriding.

Don't you mind if I create a PR?

Comment From: snicoll

Don't you mind if I create a PR?

Not assigned, so no :) I don't know how I'd fix it though but we can discuss based on your proposal. Thanks!

Comment From: snicoll

Looking at EnableNeo4jRepositories and EnableCassandraRepositories the former has a reference to sessionFactory so I think renaming that makes it harder than it should be. With that perspective, I believe this is a bug in Spring Data: AbstractCassandraConfiguration has a sessionFactory bean while @EnableNeo4jRepositories expects the default SessionFactory to be named sessionFactory.

Paging @mp911de for feedback.

Comment From: mp911de

Also paging @michael-simons. In Spring Data Cassandra, we could rename the SessionFactory bean to cassandraSessionFactory. As we have a major version jump, that change should straight-forward to communicate in our migration guide. I suggest a similar approach for Neo4j.

Internally, Spring Data Cassandra looks up as of 3.0 the session factory by type.

Comment From: michael-simons

Feel free to adapt SDN, @mp911de We are a bit swamped and I don't have the capacity to read through Boot code atm.

Comment From: mp911de

We would reflect the same changes in our AbstractCassandraConfiguration classes, too to keep the Boot config style and the module config style in sync.

Comment From: mp911de

For consistency, I suggest renaming Neo4j's sessionFactory to neo4jSessionFactory and configuration to neo4jConfiguration in Neo4jOgmSessionFactoryConfiguration.

Comment From: snicoll

Blocked by https://jira.spring.io/browse/DATACASS-713 - we'll update the bean name accordingly once this is changed in Spring Data Cassandra. We also have an issue for Neo4j but they can't make a change now as they're not shipping a major. The cassandra change will be enough to fix the scenario on master.

@aquasika it should be noted that the following scenario only occurs because you have a custom Cassandra configuration. For the time being, please override the name of the bean in your configuration, something like:

@Bean(name = "cassandraSessionFactory")
@Override
public SessionFactory sessionFactory() {
    return super.sessionFactory();
}

I've moved this issue to 2.3.x accordingly.

Comment From: snicoll

So it turns out there is nothing to do on our side. The changes made in Spring Data Cassandra fixes the issue in 2.3.x and the workaround I've provided works for earlier versions.