[Spring Data MongoDB 5.0] Preserve DefaultMessageListenerContainer startup behaviour

Parent tracking issue

• #1081

Prerequisite

• #1082 provides the Spring Data MongoDB 5 migration composite.

What problem are you trying to solve?

In Spring Data MongoDB 4.x, DefaultMessageListenerContainer#isAutoStartup() always returns false. Spring Data MongoDB 5 changes the default to true and adds setAutoStartup(boolean) for explicit configuration.

As a result, a DefaultMessageListenerContainer that is registered as a Spring-managed bean and relies on the previous default will be started by Spring's SmartLifecycle processing during application-context startup after migration. If subscriptions have been registered, their listener tasks will start at that point rather than waiting for an explicit call to start().

This can change application sequencing without any corresponding application source change. For example, an application may intentionally delay listener startup until another component is ready, a feature flag is enabled, or leadership has been acquired.

The migration objective is to preserve the Spring Data MongoDB 4.x manual-start behaviour for affected Spring-managed containers by configuring autoStartup to false explicitly where this can be done safely. It is not to guess whether an application would prefer the new automatic-start behaviour.

Instances that are not managed by the Spring application context are not started automatically merely because this default changed and should not be modified solely on that basis.

Proposed solution

Add a focused recipe or diagnostic that:

• Identifies Spring-managed DefaultMessageListenerContainer instances, including common Java @Bean methods that directly construct or return the container.
• Detects containers that do not already configure startup behaviour explicitly.
• Preserves the previous default where unambiguous by adding an equivalent of container.setAutoStartup(false) before the container is exposed as a Spring bean.
• Leaves containers with explicit startup configuration unchanged.
• Does not modify non-Spring-managed instances solely because the SmartLifecycle default changed.
• Produces a clear diagnostic where bean ownership or lifecycle configuration is too indirect or dynamic to preserve mechanically with confidence.
• Composes the completed recipe into the MongoDB 5 migration composite introduced by #1082.

The implementation should prioritise common Java @Bean configuration patterns. XML support should only be included where the relevant rewrite infrastructure and test coverage make the transformation precise.

Out of scope

• Changing unrelated Spring lifecycle configuration.
• Opting applications into the new automatic-start behaviour when they previously relied on manual startup.
• Guessing application intent where startup behaviour is already explicit or dynamically configured.
• Modifying DefaultMessageListenerContainer instances that are not managed by Spring solely because their class default changed.
• MongoDB dependency alignment, value representation configuration, or removed JMX support.
• Spring Boot-owned auto-configuration package migrations.

Acceptance criteria

• Spring-managed DefaultMessageListenerContainer instances relying on the Spring Data MongoDB 4.x false default can be identified.
• Unambiguous affected configurations are updated to set autoStartup to false explicitly.
• Existing explicit startup settings remain unchanged.
• Non-Spring-managed instances are not changed solely because of the new default.
• Ambiguous bean ownership or lifecycle cases produce a useful diagnostic instead of a speculative change.
• Tests cover affected @Bean configurations, explicit true and false settings, non-Spring-managed instances, ambiguous configurations, irrelevant code, and idempotency.
• The completed recipe is composed into the MongoDB 5 migration composite.

References

• Spring Data MongoDB 4.x to 5.x migration guide: https://docs.spring.io/spring-data/mongodb/reference/migration-guide/migration-guide-4.x-to-5.x.html
• Spring Data MongoDB 4.5.x implementation (isAutoStartup() returns false): https://github.com/spring-projects/spring-data-mongodb/blob/4.5.x/spring-data-mongodb/src/main/java/org/springframework/data/mongodb/core/messaging/DefaultMessageListenerContainer.java
• Spring Data MongoDB 5.0.x implementation (autoStartup defaults to true): https://github.com/spring-projects/spring-data-mongodb/blob/5.0.x/spring-data-mongodb/src/main/java/org/springframework/data/mongodb/core/messaging/DefaultMessageListenerContainer.java

Start by locating the MongoDB 5 migration composite introduced by #1082 and the recipe patterns for Java @Bean methods returning DefaultMessageListenerContainer. Trace how managed versus non-managed containers and explicit startup settings can be identified. Done means unambiguous managed containers receive autoStartup=false, ambiguous cases produce diagnostics, tests cover the listed scenarios, and the recipe is composed into the migration.