You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As discussed on the gitter channel, if a user wants to create their own MessageSource bean, and use the properties from application.properties, he/she will not be able to inject those properties as an object, because those properties are fields on the MessageSourceAutoConfiguration class.
It would be nice to have a MessageSourceProperties object that holds the application properties of the MessageSource. However, as @dsyer explained, the the ApplicationContext is a MessageSource so that code gets executed super early and it was probably a defensive move to prevent too many things being initialized too early. It is well worth investigating how to overcome this issue.
The text was updated successfully, but these errors were encountered:
We're binding directly to an auto-configuration class rather than to a dedicated configuration properties class. That's unusual and it'd be nice to remove the inconsistency. However, @dsyer wondered if the application context being a message source may make doing so a bit difficult.
As discussed on the gitter channel, if a user wants to create their own
MessageSource
bean, and use the properties fromapplication.properties
, he/she will not be able to inject those properties as an object, because those properties are fields on theMessageSourceAutoConfiguration
class.It would be nice to have a
MessageSourceProperties
object that holds the application properties of theMessageSource
. However, as @dsyer explained, the theApplicationContext
is aMessageSource
so that code gets executed super early and it was probably a defensive move to prevent too many things being initialized too early. It is well worth investigating how to overcome this issue.The text was updated successfully, but these errors were encountered: