-
Notifications
You must be signed in to change notification settings - Fork 40.5k
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
Propose new spring.autoconfigure.exclusion property binding as Map to support multiple property sources #41669
Comments
It's a good idea, It would be great if Spring Boot introduce the new |
We'd like to investigate #41830 to see if we can offer a general purpose solution for merging lists. I'll put this one on hold until we've done that. |
This proposal follows the way of Spring Boot, could you elaborate the disadvantage of this proposal? |
I like the new proposal as well but I think it's prudent to investigate if a general purpose solution is viable before we offer too many ways of doing the same thing. One concern I have with the new proposal is the confusion that might arise by having two very similar properties that work in slightly different ways. We'd need |
I'm vote for
I suggest deprecating it in next minor release and remove it next major release with a dedicated |
Thanks for the update!
I agree could be confusing, I think I initially had {
"properties": [
{
"name": "spring.autoconfigure.exclusions-map",
"type": "java.util.Map<java.lang.Class, java.lang.Boolean>",
"description": "Auto-configuration classes to exclude."
}
]
} for type hints, which give IDE assistance (IntelliJ) ![]() ![]() I did consider whether should deprecate too, I don't have any overly strong opinions either way should the new property be ultimately agreed too. However if the old is not deprecated, then both should be supported simultaneously (not mutually exclusive) IMO, as my env post processor does. Also not against, #41830, but I am interested how this might work with collections of complex types that themselves might have nested collections - I'll repost that last question on that ticket too. |
Currently the
spring.autoconfigure.exclude
property is bound as aList<Class<?>>
. This is a problem as collections cannot be merged across different property sources or individual elements removed. Additionally it requires property sources with higher precedence to have global knowledge of all preexisting exclusion from other sources in order to append a new exclusion.This is a frequent pain-point for us and others. See #27414 - Consider merging spring.autoconfigure.exclude from multiple profiles and #9137
Understandably merging / overriding logic for collections is difficult - refer to #12444 (comment)
I propose a new configuration property (E.g.
spring.autoconfigure.exclusions
or perhaps some other property if too similarly named) that is bound as aMap<Class<?>, Boolean>
. Binding to a map will allow merging from different property sources and profiles. E.g.Including the class name in the key is not too different from the
logging.level.<class>
properties and similar tomanagement.health.<name>.enabled
.I have a custom EnvironmentPostProcessor that I think achieves my goal by rebinding the
spring.autoconfigure.exclude
property from my customspring.autoconfigure.exclusions
property? But it would be nice if spring-boot had first class support for this. For posterity here it isThe text was updated successfully, but these errors were encountered: