Ensure that all data store auto-configurations have consistent default connection behaviour

This was raised as part of a discussion on Twitter. The specific example given is Mongo which connects to localhost when it’s on the classpath and Couchbase which doesn’t connect to anything until your configure at least one bootstrap host.

There may well be good reasons for the apparent inconsistency, but it appears to be causing some confusion. It would be nice to align the behaviour across data stores if we can. If there are good reasons not to do that, it would be nice to see if we can somehow make the varying behaviour less surprising.

[abelsromero]

The confusion for us came because of two reasons One, we have been using Couchbase without issues, and when we migrated to MongoDB we had to exclude the autoconfigurer. That felt odd.

Two, how the Autoconfiguration starts and logs the MongoClient behauviour…

1. if MongoClient is in the classpath and no configuration is present, it attempts to connect a localhost instance.
2. If connection fails, it does not propagate the error, so the context starts and the app is working fine.
3. However, the error is logged into the logs just after the "success"message. See attachment. mongoclient-springboot-autcoonfigurer-error.txt

Note: whe use a logback logging configuration importing springs defaults

    <include resource="org/springframework/boot/logging/logback/defaults.xml"/>

Imho, all Autoconfigurators for components depend on some mid-complex configuration should check for properties. Simple things or when a default config is a common thing like Gson or Jackson are fine that they only check for Beans.

Btw, the reason why we have a custom connector and do not expose a MongoClient to the Spring context is because we have a multitennacy platform that manages several connections at once. We load the configurations from a config-service and then initialize all our MongoClients inside a custom bean. That bean is the exposed, but not the clients.

[wilkinsona]

Neo4j is also affected in a similar way. An app will fail to start when Neo4j can’t be reached. #23707 contains some details, including failures both with and without Actuator.