Legacy MongoClient conflict when declared explicitly as Bean

[nishkarsh]

I am working on a spring boot project with JaVers integrated along with spring-boot-starter-data-mongodb.

I had to configure MongoClient for some encryption settings for which I need to explicitly create it as a Bean. The newer version of mongo java driver (since version 3.7) recommends that the MongoClient is created using MongoClients class which creates an instance of com.mongodb.client.MongoClient (source). When this happens, the application produces an error as JaVers is expecting a legacy version of MongoClient.

Field mongoClient in org.javers.spring.boot.mongo.JaversMongoAutoConfiguration required a bean of type 'com.mongodb.MongoClient' that could not be found.

The injection point has the following annotations:
	- @org.springframework.beans.factory.annotation.Autowired(required=true)

The following candidates were found but could not be injected:
	- Bean method 'mongo' in 'MongoAutoConfiguration' not loaded because @ConditionalOnMissingBean (types: com.mongodb.MongoClient,com.mongodb.client.MongoClient; SearchStrategy: all) found beans of type 'com.mongodb.client.MongoClient' mongoClient


Action:

Consider revisiting the entries above or defining a bean of type 'com.mongodb.MongoClient' in your configuration.

This forces me to stay with the legacy MongoClient that doesn't have a nice builder to accept various settings.

[bartoszwalacik]

Hi, consider contributing a PR with the mongo client version bump

[bartoszwalacik]

@nishkarsh unfortunately, MongoAutoConfiguration from Spring still produces the old com.mongodb.MongoClient which makes things messy

[nishkarsh]

@bartoszwalacik You are right, springboot autoconfigure still provides the legacy MongoClient as of now. However, I checked the commit here that seems to have the change in MongoAutoConfiguration to provide com.mongodb.client.MongoClient which is tagged for 3.0.0 release. Since the 3.0.0.RC2 is already out, I believe the stable would be out soon too. Moving to the newer version, however, would probably take even longer.

The main reason I had raised this issue was because JaVers fails when a new MongoClient is explicitly declared as a Bean since MongoAutoConfiguration wouldn't produce the legacy MongoClient then either. We could probably do something to make sure JaVers support both and doesn't necessarily @Autowire only legacy MongoClient. A bit of an effort but I don't have an option in my project right now and I am forced to stay on the legacy MongoClient because of this issue.