[hibernate-dev] Message-Templates from multiple JARs

Emmanuel Bernard emmanuel at hibernate.org
Tue Feb 16 03:46:47 EST 2010


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 violating encapsulation).

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:

> Hi,
> 
> 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 strategy
> which allows for multiple resource bundles. You would specify the strategy in the hibernate
> config file. The names for the different resource files could also be specified in the
> config (or maybe there is a better way!?)
> 
> --Hardy
> 
> 
> On Mon, 15 Feb 2010 16:51:13 -0300, Gunnar Morling <gunnar.morling at googlemail.com> wrote:
> 
>> 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.
>> 
>> WDYT?
>> 
>> Cheers, Gunnar
>> 
>> 
>> 2010/2/15 Emmanuel Bernard <emmanuel at 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
>>> 
>>> 
> 





More information about the hibernate-dev mailing list