Re: [hibernate-dev] Message-Templates from multiple JARs

----- "Emmanuel Bernard" <emmanuel(a)hibernate.org&gt; wrote: > 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). You must be developing small or monolith applications then ;) The common way I know of (from eclipse apps) is that the resource bundles *specific* to that module/plugin is stored in the module and if there are some common phrases/messages they are simply put into separate module/plugin or you simply depend on that module/plugin you want to share that common phrase with.

> 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). Not following this, additional resource bundles is/should be possible to add translations to 3rd party components without changing it. -max > > 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(a)googlemail.com&gt; 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(a)hibernate.org&gt; >>> >>>> 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 >>>> >>>> >> > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev -- /max