Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Revise Abstract…MongoConfiguration to expose more bean detail and avoid proxying [DATAMONGO-2355] #3213

Closed
spring-projects-issues opened this issue Sep 2, 2019 · 3 comments
Assignees

Comments

@spring-projects-issues
Copy link

@spring-projects-issues spring-projects-issues commented Sep 2, 2019

Andy Wilkinson opened DATAMONGO-2355 and commented

The signatures of both reactiveMongoTemplate and reactiveMongoDbFactory provide less type information than they could. This can result in obscure dependency injection failures as the type information available to the bean factory varies depending on whether or not the injection attempt is being performed before or after the bean has been instantiated. It can also lead to unexpected bean condition failures as described in the referenced Stack Overflow question


Affects: 2.1.10 (Lovelace SR10)

Reference URL: https://stackoverflow.com/questions/57761228/spring-boot-2-1-duplicate-reactivemongotemplate-bean

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Sep 3, 2019

Herman Bovens commented

If the idea is that users can inject ReactiveMongoOperations instead of ReactiveMongoTemplate (for easier mocking/stubbing etc.) then probably reactiveMongoTemplate should not be autoconfigured when any ReactiveMongoOperations bean is already registered.  So I guess this may be fixed by using @ConditionalOnMissingBean(ReactiveMongoOperations.class) on reactiveMongoTemplate.  This is similar to the mappingMongoConverter bean which is annotated with @ConditionalOnMissingBean(MongoConverter.class).

I guess this would apply to the regular (non-reactive) mongoTemplate bean in MongoDbFactoryDependentConfiguration as well

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Sep 3, 2019

Andy Wilkinson commented

You make a good point about the mocking use case. Thanks. I've opened spring-projects/spring-boot#18101 so that we can address that in Spring Boot. Even with that change in Boot, I think there's still value in a change being made in Spring Data MongoDB so that its bean definitions provide a much type information as possible to the bean factory

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Mar 10, 2020

Mark Paluch commented

After investigating the setup in other modules, we have now the chance to align with these in the sense of exposing the actual bean type. We're going do address this ticket for the upcoming MongoDB 3.0 version.

It makes sense to improve our config classes to avoid the need for CGlib proxies (@Configuration(proxyBeanMethods = false)) as we may introduce breaking changes with the current major version bump

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants