Doc: ReloadableResourceBundleMessageSource's setUseCodeAsDefaultMessage causes the ValidationMessages.properties to not be found and used correctly [SPR-15986]

[spring-projects-issues]

Happy opened SPR-15986 and commented

There are a few issues with using ```java
ReloadableResourceBundleMessageSource

1)Hibernate ValidationMessages.properties is not discovered 

When injecting a new ```java
ReloadableResourceBundleMessageSource
``` into 

```java 
  @Bean
  public SpringValidatorAdapter springValidatorAdapterFactory()
  {
    LocalValidatorFactoryBean springValidatorAdapter = new LocalValidatorFactoryBean();
    springValidatorAdapter.setValidationMessageSource(messageSource);// <-- here
    return springValidatorAdapter;
  }

then the messages from teh hibernate ValidationMessages.properties are picked and displayed accurately.

When I use ```java
ReloadableResourceBundleMessageSource

```java 
   @Bean
  public MessageSource messageSource()
  {
    ReloadableResourceBundleMessageSource messageSource = new ReloadableResourceBundleMessageSource();
    messageSource.setBasenames(MESSAGE_SOURCE_BASE_NAMES); //path to i18n/messages
    messageSource.setUseCodeAsDefaultMessage(true);
    messageSource.setDefaultEncoding(UTF8_ENCODING);
    messageSource.setFallbackToSystemLocale(false);
    messageSource.setCacheSeconds((int) TimeUnit.HOURS.toSeconds(1));
    return messageSource;
  }

the ValidationMessages.properties file is never scanned.

However, when I set the following to false, comment from the above

// messageSource.setUseCodeAsDefaultMessage(true);

The ValidationMessages.properties from hibernate is correctly loaded.

I wouldn't have thought UseCodeAsDefaultMessage would cause this problem. But it does.
I have also faced problems as discussed in https://stackoverflow.com/q/23448360/1083581 and commenting out useCodeAsDefaultMessage has fixed errors. It however exposes my app to show errors when message codes aren't found.
I am using 4.3.4-RELEASE of spring-context.

---

Affects: 4.3.5

Referenced from: commits 37ab8a7, ce94026

Backported to: 4.3.15

[spring-projects-issues]

Juergen Hoeller commented

I'm afraid this is a limitation of the underlying design here. Hibernate Validator's extension that we're relying on there only provides us with a resolution callback before its default algorithm, so Spring's MessageSource is being called first: When it resolves a message, that's what Hibernate Validator goes with - even if it's produced by useCodeAsDefaultMessage. So it is indeed recommendable to stick with useCodeAsDefaultMessage=false, since that's the only way to let Hibernate Validator evaluate its own default messages as a fallback.

From that perspective, the only step we can take here is to explicitly document this.