Context: We can use the H2 database if we don't want to connect to a real DB during developments. I want the same functionality for Embedded MongoDB as well.

Problem: If we add embedded MongoDB dependency, but remove the test scope, then even if a real database URI value is given in spring.data.mongodb.uri, the EmbeddedMongoAutoConfiguration ignores that and connects to the embedded one

Proposal: Allow EmbeddedMongoAutoConfiguration to back-off, when spring.data.mongodb.uri property is present

Comment From: odrotbohm

Moved to Boot as per @christophstrobl's request.

Comment From: ztomic

You can disable EmbeddedMongoAutoConfiguration with application configuration for workaround:

spring:
  autoconfigure:
    exclude:
      - org.springframework.boot.autoconfigure.mongo.embedded.EmbeddedMongoAutoConfiguration

Comment From: SujanKumarMitra

You can disable EmbeddedMongoAutoConfiguration with application configuration for workaround:

yaml spring: autoconfigure: exclude: - org.springframework.boot.autoconfigure.mongo.embedded.EmbeddedMongoAutoConfiguration

Yes, but it would be better if it automatically does that, like it works for H2

Comment From: wilkinsona

Allow EmbeddedMongoAutoConfiguration to back-off, when spring.data.mongodb.uri property is present

We can't do that as it would mean that those using embedded Mongo for testing (its primary use case in a Spring Boot app) would no longer be able to do so if they'd configured spring.data.mongodb.uri for use at runtime.

Unfortunately, the H2 analogy doesn't really hold up. H2 is "just" a DataSource and once configured it works in the same way as any other DataSource. Switching between H2 and an external database is only a matter of changing the DataSource bean in the context. In Mongo terms, it's really MongoClient that's the equivalent of a JDBC DataSource. Embedded Mongo provides a backend with which the MongoClient communicates. These differences mean that we can't easily make H2 and Embedded Mongo behave in the same way.

If you don't want to use Embedded Mongo for testing and are happy for the presence of a spring.data.mongodb.uri property to cause a connection to be made to your "real" mongo instance, then excluding the auto-configured is probably your best option. Thanks, @ztomic for making the suggestion. An advantage of disabling the auto-configuration is that embedded Mongo won't be started when you're not going to use it.

Another option would be to define your own MongoClientSettings bean that's conditional on the spring.data.mongodb.uri property having been set. You'd then configure these settings with the URI (and any other configuration you need). Its presence would cause the Mongo auto-configuration to back off and to no longer look for the local.mongo.port property that's used to connect to the embedded instance. This has the disadvantage that embedded Mongo would still be started even though it's not going to be used.

My feeling is that we should not do anything here. As I said above, the primary usecase for embedded Mongo is for test purposes and we don't want to disrupt that. If you want to use embedded Mongo outside of your tests, excluding the auto-configuration will already give you the end result that you want. I also, to some extent, regret adding auto-configuration for embedded Mongo in the first place. Our CI shows that it can be a little unstable and I think that running Mongo via Testcontainers is a better option these days.

I'll flag this for team attention to see if anyone else on the team has some suggestions.

Comment From: SujanKumarMitra

@wilkinsona

Our CI shows that it can be a little unstable

Yes, when using EmbeddedMongo, sometimes I need to call the block() operator just to get the test cases pass. Using StepVerifier does work for some reason.

I guess for the dev profiles, I need to manually configure a throw-away mongo DB via Testcontainer's MongoDBContainer. If any other options are present, please suggest them.

Comment From: wilkinsona

We've discussed this today and decided that we're going to leave things as they are. Thanks anyway for the suggestion.