Looking for a documentation of the most elegant way of configuring custom converters for spring data mongodb is not very clear. The spring data docu states:
If you want to rely on Spring Boot to bootstrap Data MongoDB, but still want to override certain aspects of the configuration, you may want to expose beans of that type. For custom conversions you may eg. choose to register a bean of type MongoCustomConversions that will be picked up the by the Boot infrastructure. To learn more about this please make sure to read the Spring Boot Reference Documentation.
But when you follow to the spring boot docu there is not a single mentioning of the MongoCustomConversions.
A simple example would have been beneficial:
@Bean
public MongoCustomConversions customConversions(){
return new MongoCustomConversions(List.of(<custom converters>));
}
The extend AbstractMongoClientConfiguration example is kind of more prominent, but for the purpose of only customizing the converters an overdo
Comment From: wilkinsona
Unfortunately, it isn't practical to provide examples for every bean that's auto-configured showing how it can be overridden as it would make the documentation overly verbose. Instead, we prefer to take advantage of the fact that Spring Boot is open source and that you can use the condition evaluation report that see what is being auto-configured and why.
If you start an app that uses Spring Data MongoDB with --debug, you'll see something similar to the following in the output:
============================
CONDITIONS EVALUATION REPORT
============================
Positive matches:
-----------------
…
MongoDataConfiguration#mongoCustomConversions matched:
- @ConditionalOnMissingBean (types: org.springframework.data.mongodb.core.convert.MongoCustomConversions; SearchStrategy: all) did not find any beans (OnBeanCondition)
From this you can learn that mongoCustomConversions was auto-configured because there was no existing MongoCustomConversions bean in the context. This means that it will back off if you define your own. You can also look at the problem from those other side and start with the auto-configuration classes that are listed in the appendix.
The benefit of this approach is that it is generally applicable to any auto-configuration. Thanks anyway for the suggestion but we feel that our current approach is more practical approach as it doesn't require individual examples in the reference documentation for every single different bean that Spring Boot can auto-configure.