(I published this same proposal also on the forum, and copying it here so that it does not get lost)
This is a proposal for the new version of JSR 303 (v1.1 ?).
The proposal is: modify the default message interpolation algorithm (section 220.127.116.11) so that the validation engine looks for a Resource Bundle called ValidationMessages in the constraint annotation's own package.
For example, when validating constraint annotation com.gdpcons.constraints.MustEqual, validator should also look for messages in a resource bundle called com.gdpcons.constraints.ValidationMessages.
The constraint annotation package ValidationMessages resource bundle should be checked after the "user" ValidationMessages resource bundle, but before the BeanValidation provider's own private ValidationMessages resource bundle, so as to allow users to override the string provided by the constraint annotation resource bundle.
This would allow people to write redistributable collections of constraint annotations, since as of today it's not possible to use multiple ValidationMessages resource bundles files (one will override all the others in the classpath); and it would still allow users to override the provided messages just by a new definition for the message key in their own ValidationMessages resource bundle.
I've written an example implementation, by modifying Hibernate Validator's own ResourceBundleMessageInterpolator. It seams to work without side effects, and is a very straightforward implementation.
See it attached to this issue.
Must have. I'm not sure about the exact form, but we definitely should it make easier to create reusable constraint libraries.
Unfortunately that won't cut it (time). I feel like this is something that could be coupled with the idea of making it simpler to build libraries of constraints with automatic impl and default resource bundles. Let's try and build that in Hibernate Validator before moving in the spec.
I am having the same need for this. Initially I wanted to suggest that all /ValidationMessages[_*].properties shall be loaded from the classpath but the approach suggested here is better as it prevents problems with classpath ordering.
Please also note that GWT provided their own way to address this problem. See at the end of this: