Using Spring Session Redis prevents you from creating your own bean named redisMessageListenerContainer

Via this Stack Overflow question, Spring Session Redis creates a bean named redisMessageListenerContainer that prevents a user from creating their own bean with that name. A bean will either get overridden or, if overriding is disabled as it is by default in Spring Boot 2.1, a startup failure will occur.

The quickest solution would be to name Spring Session’s bean more specifically. redisMessageListenerContainer is a very generic name for a piece of Spring Session’s infrastructure. I think it would also be interesting to consider solutions beyond that and take a look at whether it needs to be a RedisMessageListenerContainer bean at all. If the listener container is intended to be used solely by Spring Session, it would seem to make sense for it to not be exposed as a RedisMessageListenerContainer bean. If it’s intended to be a general purpose component, then it would seem to make sense for Spring Session to be able to reuse an existing listener container rather than always creating its own.

[vpavic]

Another point is that I don’t believe (correct me if I’m wrong) that exposing this as a Bean with a unique name is going to impact many users since they are not unlikely to autowire RedisMessageListenerContainer by type. This differs from RedisTemplate, for example, since users are likely to autowire it by type.

I agree, this is a valid point. Prefixing the bean name springSession should address this without us having to add too much complexity.

[rwinch]

Thanks for the clarifications.

I’d prefer to stick with Spring Data’s contract which is exposing it as a Bean. Wrapping it seems to read into the implementation a bit too much. For example, if RedisMessageListenerContainer adds more lifecycle methods we would need to make sure we support those too. Another point is that I don’t believe (correct me if I’m wrong) that exposing this as a Bean with a unique name is going to impact many users since they are not unlikely to autowire RedisMessageListenerContainer by type. This differs from RedisTemplate, for example, since users are likely to autowire it by type.

In short, unless we have sufficient reason to do otherwise I’d prefer to stick with exposing it as a Bean using a more unique bean name.