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.
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.
ValidationMessages.properties in the Jar file (has been stored)ValidationMessages.properties is stored (has been stored) in each module.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 ...)
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).
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.
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 ...
ValidationMessages.properties directly under the classpath (only one file is valid if there are multiple)ContributorValidationMessages.properties directly under the classpath (all files are valid)It will be.
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