I don't see i18n as something that should necessarily be packaged inside a component.
Resource keys are generally grouped in one or two files for the overall application (so
that fixing a typo is quick). If you have to dig into individual or even third party
components, it becomes a pain point. So I don't see that as encapsulation violation
(or at this stage, you have to consider that displaying the error message to the user is
You would put the @ResourceBundle on the constraint annotation? I don't like the idea,
it would encourage the creation of a myriad of different resource bundle files. Also today
the spec allows to inject your own ResourceBundle implementation via the
MessageInterpolator (will even be better in Hibernate Validator after HV-238). Adding a
@ResourceBundle will clash with this freedom.
Another point I want to mention, Hibernate Validator 3.x had support for a more
sophisticated RB approach but it turned out to be a big ball of inconsistency and holes
and I purposely simplified the model in Bean Validation.
On 15 févr. 2010, at 21:36, Hardy Ferentschik wrote:
Having multiple resource bundles and some custom way of specifying these bundles is
related to HV-238 and HV-251.
Having a ResourceBundleLocatorStrategy should solve your problem Gunnar, right?
The default strategy could behave like it does now and we can provide an additional
which allows for multiple resource bundles. You would specify the strategy in the
config file. The names for the different resource files could also be specified in the
config (or maybe there is a better way!?)
On Mon, 15 Feb 2010 16:51:13 -0300, Gunnar Morling <gunnar.morling(a)googlemail.com>
> I agree, there probably won't be that many 3rd-party constraint vendors :-)
> Nevertheless I think the problem is not too exotic. In my day job for
> example we're building a large-scale enterprise application, which is made
> up of multiple JARs ("components") developed by multiple, independent
> development teams.
> Now it would be great, if two teams could develop independently their custom
> constraints, specific to their component. As of now they would have to
> provide a unified ValidationMessages.properties, violating the encapsulation
> of the components.
> A rather simple solution might be a meta-annotation @MessageBundle, which
> optionally could be used at constraint annotation type declarations to
> specify the name of the message bundle to be used. That way name collisions
> between constraints from different JARs still could occur, but finding
> unique names should not be too hard. If that meta-annotation is not given, a
> fallback to ValidationMessages.properties might be used.
> Cheers, Gunnar
> 2010/2/15 Emmanuel Bernard <emmanuel(a)hibernate.org>
>> Yes, you need to copy it over or more likely adapt the messages to your
>> application (in which case you don't care).
>> The problem with listing the resource bundle is that you need an order to
>> specify which has precedence over which.
>> Another solution could be some sort of plugin system where 3rd party
>> constraint makers can reference automatically a resource bundle. But
>> realistically, how many 3rd party constraint makers will there be?
>> The question is: is the additional complexity for the solution worth the
>> current problem?
>> On 14 févr. 2010, at 22:00, Gunnar Morling wrote:
>> > Hello you two,
>> > recently I thought about the following situation:
>> > * I have a JAR containing a custom constraint on the class path (could be
>> a constraint provided by some 3rd-party constraint vendor)
>> > * I have another custom constraint within the actual project itself (and
>> therefore a ValidationMessages.properties as well)
>> > Now the ValidationMessages.properties provided by the 3rd-party vendor is
>> hidden by my own ValidationMessages.properties, which - if I'm not mistaken
>> - requires me to copy the contents of the first to the latter.
>> > Is there any better solution to this problem?
>> > Maybe BV/HV should provide some means for constraint vendors to specify
>> the resource bundle containing messages? If you think, that's useful I'd
>> create a JIRA issue for that one.
>> > Thanks for any ideas,
>> > Gunnar