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(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

----- "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 _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

On Tue, 16 Feb 2010 18:41:12 -0300, Gunnar Morling <gunnar.morling(a)googlemail.com&gt; wrote: > I agree with Max, I think there should be some way for packaging message > bundles within components containing constraint annotations, while > offering > the possibility to optionally override these with custom messages if > required. > > With respect to large-scale enterprise apps, I guess it can become quite > impractical to demand, that all component teams provide one single > message > bundle. Also having to copy contents of message bundles from 3rd-party > libs > containing constraint annotations to the local bundle could get somewhat > tedious. > > Providing a custom MessageInterpolator might be viable, nevertheless I > think, such a mechanism should work out of the box. Well, having a simple configuration option is almost like "out of the box". For most cases the default behavior will be good enough and for the few cases a simple configuration option will do the trick. > Not sure though, what the best solution here is. I also thought about > merging the ValidationMessages.properties from different > libraries/components (similar to what java.util.ServiceLoader does) into > one > bundle, giving the contents from the local ValidationMessages.properties > precedence. That way components could provide message texts for their > constraints (name clashes are possible but actually shouldn't happen, as > message keys should be fully-qualified), while offering the possibility > to override these texts within the local bundle if required. This could be one of the custom ResourceBundleLocator strategies we have been talking about. --Hardy _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev