ValidationMessages.properties should not be multiple on the classpath

Bean Validation (hereinafter "BV") messages (default messages provided by providers such as Hibernate Validator (hereinafter "HV")) create ValidationMessages.properties (file for each language because it is a resource bundle) directly under the classpath. You can change it by doing.

For example ... When using HV as a provider, the default messages of @ Size (constraint annotation provided by VB) and @ Length (constraint annotation provided by HV) are as follows.

Message definition in HV jar file


javax.validation.constraints.Size.message = size must be between {min} and {max}
org.hibernate.validator.constraints.Length.message = length must be between {min} and {max}

If you want to change this message ...

src/main/resources/ValidationMessages.properties


javax.validation.constraints.Size.message = 'Size' must be between {min} and {max}.
org.hibernate.validator.constraints.Length.message = 'Length' must be between {min} and {max}.

You can change it to any message.

What if you have multiple ValidationMessages.properties?

Then, when there are multiple ValidationMessages.properties ... What exactly is it? In the case I was involved in, there was a situation where ValidationMessages.properties existed in the following two patterns.

Does the BV specification support multiple files?

As far as I've skimmed the BV spec, I didn't mention multiple files, so it seems that the standard doesn't support multiple files. (Since English is weak, it may be read ...)

What if there are more than one?

I haven't suppressed the small movements, but ... If you use HV as a provider, one of the files will be valid. Probably the file with the higher priority of the classpath is used, but if the priority cannot be explicitly specified like the jar file in the lib of the web application (war), the implementation of the application server etc. It is also expected that the files enabled by will change. ↓ As a result, the expected message disappears when the specified message is assumed for the file that did not become valid (→ that is, a bug).

BV specification compliant measures

If you are particular about BV specification compliance, delete ValidationMessages.properties in the library or submodule and control so that ValidationMessages.properties is one on the classpath when the application is executed.

Countermeasures using HV functions

If you are not particular about BV specification compliance and assume that you will use it on + HV, [HV original message definition reading function mechanism](https://docs.jboss.org/hibernate/stable/validator/reference/ You can use en-US / html_single /? v = 6.0 # _constraint_definitions_via_code_serviceloader_code). Specifically ... Please change to store ContributorValidationMessages.properties instead ofValidationMessages.properties directly under the Jar file of the library or submodule. This will allow the HV to read all the ContributorValidationMessages.properties that are on the classpath and build the message for you.

If you organize the priority order of message definitions (in descending order of priority) when using HV ...

It will be.

Verification app

Summary

If the library is intended for use on HV, it seems better to define the default message in ContributorValidationMessages.properties and distribute it. Even if you use it on a provider other than HV, it shouldn't be bad ...

Recommended Posts

ValidationMessages.properties should not be multiple on the classpath
Map keySet, values should not be used
The story that I could not build after installing multiple Java on Windows
Using templates on the classpath with Apache Velocity
The story that the variable initialization method called in the Java constructor should not be overridden
[Android] Solution when the camera cannot be started on Android 9
[Java] When var should be used and when it should not be used
The story that the forced update could not be implemented
Solved the problem that apt-get update could not be executed on Ubuntu (Virtual Box) on Windows.