MongoClientFactorySupport overrides existing uuidRepresentation with MongoProperties default value

[christophstrobl]

Original Bug Report: DATAMONGO-2561

I have MongoClientSettings bean defined in my configuration with STANTARD uuid representation.
After migration to spring 2.3.0 this value is always overridden by MongoProperties.uuidRepresentation.
MongoProperties.uuidRepresentation is a field with default value JAVA_LEGACY and even when spring.data.mongodb.uuidRepresentation property is not defined, the default value is used instead of one defined in MongoClientSettings.

MongoClientFactorySupport should check if the source MongoClientSettings passed to createClient already define an uuidRepresentation other than UNDEFINED before applying the default value from MongoProperties that then potentially overrides existing settings.

[snicoll]

Thanks for the report. Things have changed quite a lot in 2.3.x. In 2.2.x we had a MongoClientOptions with a bunch of settings that could be set by the user. If it was, the auto-configuration would take it and leave it untouched.

With the change of API, this turned into a MongoClientSettings. I can see that if that bean is set, the auto-configuration mutates it which feels a bit wrong to me. It does it because the scope of that object goes beyond what MongoClientOptions used to do. It basically encompasses all settings that the MongoClient needs.

For consistency, I think we should take that bean as is and not apply any properties customization to it when it is defined. Flagging for team attention to get some more feedback from the team.

[snicoll]

Note that the 2.3.x behaviour I've described is not as new as I thought it would be. The reactive API has this MongoClientSettings and we do mutate it for reactive access in 2.2.x too.

[wilkinsona]

For consistency, I think we should take that bean as is and not apply any properties customization to it when it is defined.

The feels right to me. I do wonder how many people may be relying on the current behaviour though.

[snicoll]

We could move all that processing to a public MongoClientSettingsBuilderCustomizer. Users relying on that behaviour could apply this processing themselves when creating a custom MongoClientSettings.

I wonder if fixing this for 2.3.x only would be in order.

[scottfrederick]

After a team discussion, we've decided to leave this as-is for 2.3.x and make a change for 2.4.x.

With Boot 2.3.x, the work-around is for users to do all configuration of MongoClientSettings in a MongoClientSettingsBuilderCustomizer instead of contributing a MongoClientSettings bean. Customizers run after MongoProperties have been copied to the MongoClientSettings, so this will ensure that the desired configuration is applied.

For 2.4.x, we won't make any changes to a MongoClientSettings bean that is provided by the user.