-
Notifications
You must be signed in to change notification settings - Fork 40.8k
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
Use @EnableConfigurationProperties to define the MessageSourceProperties bean #42181
Comments
I'm not sure why |
I am not 100% sure but this might be an oversight of #13824 where we could have moved this to We have a lot of auto-configurations that rely on the absence of a bean, and then only create the configuration. So if we changed this, the user code should still have @mmoayyed in the meantime, have you tried to create the bean yourself? Does it work? @Bean
@ConfigurationProperties(prefix = "spring.messages")
public MessageSourceProperties messageSourceProperties() {
return new MessageSourceProperties();
} |
Unfortunately, no. Defining a bean directly as you note produces the same problem. Other factors that might be of interest here:
|
Thanks for the additional info. Unfortunately, it's not clear why that wouldn't work. If you have defined your own If you would like us to spend some more time investigating, please spend some time providing a complete yet minimal sample that reproduces the problem. You can share it with us by pushing it to a separate repository on GitHub or by zipping it up and attaching it to this issue. |
My apologies, I misspoke. My previous test ran a stale copy of the application without that bean defined. To be accurate, yes defining a |
Great, thanks. No need for a reproducer as I think we're all on the same page now. I think we should be able to change things such that Note that, as @snicoll mentions above, once this change is in place, if you've defined your own |
Understood, thank you very much everyone for the fix and the notes. |
Does |
Yes. |
It's not consistent with other |
@quaff Stéphane already shared what developers should to to get properties even if the auto-configuration backs off. Can you explain your use case and how you're defining your custom |
Also, why don't you think it's consistent? Any class annotated with |
My point is @Configuration
@EnableConfigurationProperties(MessageSourceProperties.class) // it should not be required
public class MyMessageSourceConfiguration {
@Bean
public MessageSource messageSource(MessageSourceProperties properties) {
...
}
} |
If we do what you're suggesting in our codebase, then Spring Boot apps would get dozens of |
I'm not against that, just point it out that developers may be confused, since most of |
Spring Boot 3.4 M2.
It appears that when one defines their own
messageSource
bean, it's not then possible to injectMessageSourceProperties
into the overriding bean for an alternative implementation to reuse certain bits of the configuration schema. That is, if I have my own:This will fail with:
I propose that alternative implementations of this bean should still be able to use
MessageSourceProperties
.This is of course because the
MessageSourceAutoConfiguration
defines the following:...and in the same class,
MessageSourceProperties
is declared as a bean:So when a competing bean is found, this prevents
MessageSourceProperties
to be created.I find this somewhat unusual that
MessageSourceProperties
is created explicitly as a Bean, and the class itself unlike many others is not tagged with@ConfigurationProperties(prefix ="spring.messages")
. I suspect that if this were the case, the problem would disappear. The binding would be recognized by the runtime and yet the bean implementation will be skipped in favor of the alternative but there may be a deeper rationale behind the change here.Thank you for your time!
The text was updated successfully, but these errors were encountered: