This PR adds support for ReloadableResourceBundleMessageSource, by adding a spring.messages.reloadable configuration property, which can be set to true to force the messageSource bean to be an instance of that class.

I'm currently working on a legacy Spring project that is progressively being migrated into Spring Boot, and we use a ReloadableResourceBundleMessageSource there, and we would like to replace it with the MessageSourceAutoConfiguration.

I'm well aware of #3039, and that:

The recommended approach since 1.3 is to use Devtools.

However, Devtools is not an option in this project, and even if it was, reloading all the application takes much more time than the ReloadableResourceBundleMessageSource takes to refresh.

I think that changes to enable ReloadableResourceBundleMessageSource support are minimal, and the new introduced configuration, spring.messages.reloadable is set to false by default, so it's backaward compatible.

Comment From: philwebb

We discussed this a little and we're not too sure on the best way to continue. It would certainly be nice to offer an easy way to plug-in a custom ResourceBundleMessageSource but we're not sure if we should do that with a property.

There is some precedent for controlling caching with properties. For example with spring.thymeleaf.cache which does a similar thing for Thymeleaf templates. We need a little more time to consider the options. If we do add property support we should also change DevTools to make use of it so a full restart isn't required.

Comment From: ruifigueira

Thanks for the input. I understand that having a configuration property that "decides" which implementation to use is not ideal at all, and I wouldn't mind if I had to explicitly declare a bean for that:

@Bean
public MessageSource messageSource() {
  return new ReloadableResourceBundleMessageSource();
}

But then, I would have to configure it myself (even MessageSourceProperties bean is not available once a MessageSource bean is explicitly declared).

One possible idea would be to configure that declared MessageSource bean in the MessageSourceAutoConfiguration using the MessageSourceProperties.

Comment From: candrews

Should dev tools set spring.messages.reloadable to true when it's active?

Comment From: snicoll

@candrews probably, yes. Can you please create a separate issue?

Comment From: wilkinsona

With some regret, we've decided to revert this change. With hindsight, we don't think that the approach taken here is quite right. In particular, setting reloadable: true breaks the default approach of placing messages files in src/main/resources which isn't ideal. We're not yet sure what the right approach should be, or if it should have a boolean reloadable property. Rather than backing ourselves into a corner by shipping this in 2.1, we'd like to give ourselves the time and freedom to consider all alternatives without having to fit the configuration model that was proposed here.

Comment From: wilkinsona

I've opened https://github.com/spring-projects/spring-boot/issues/15007.

Comment From: ruifigueira

I understand, I honestly didn't expect this to be merged, because we were still discussing if my approach was the best one. I was already convinced it wasn't, and your point regarding files placement is a very good point against this approach.

Comment From: php-coder

With some regret, we've decided to revert this change.

BTW it seems like it wasn't removed from the changelogs: - https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-2.1.0-RC1-Release-Notes#reloadable-messagesource - https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-2.1.0-RC1-Configuration-Changelog

P.S. Yes, I know it's quite old and 2.1 is EOL.

Comment From: snicoll

@php-coder this change was reverted after RC1 was released so the current changelog is accurate.