MessageSourceAutoConfiguration relies on internal method call for BeanFactory.getBean()

[dsyer]

There might be other places. This is the only one I found so far. I assume there's a weird ordering issue that made it the way it is, but it would be nice to refactor it so that CGLib isn't strictly needed to create the beans in this class.

See also #9068

[dsyer]

FWIW: this works for me:

	@Bean
	public MessageSource messageSource(MessageSourceProperties properties) {
		ResourceBundleMessageSource messageSource = new ResourceBundleMessageSource();

c.f. (from master):

	@Bean
	public MessageSource messageSource() {
		MessageSourceProperties properties = messageSourceProperties();
		ResourceBundleMessageSource messageSource = new ResourceBundleMessageSource();

[snicoll]

Yup, that's clearly not necessary.

[snicoll]

Or not ... #9666 (comment)

[dsyer]

That comment appears to be wrong or out of date. Need to test with a custom MessageSource bean to make sure, but it seems to work for a custom messages.properties (as in Petclinic for instance) with the code above.

[snicoll]

Yep, I've reached the same conclusion.

[snicoll]

That being said, I don't think this was added by accident anymore. This auto-configuration has the following:

@ConditionalOnMissingBean(value = MessageSource.class, search = SearchStrategy.CURRENT)

Assuming a hierarchy of ApplicationContext where the parent is also configured via Spring Boot, the auto-configuration could kick-in in the parent and doing such injection allows to use the expected properties set. One might argue that the set will be exactly the same so it doesn't really matter.

Not entirely sure what to do here.

[snicoll]

That will work as the bean in the child will take precedence.