[hibernate-dev] Message-Templates from multiple JARs

[Max Rydahl Andersen]

----- "Emmanuel Bernard" <emmanuel at hibernate.org> 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 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
> >>> 
> >>> 
> > 
> 
> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

-- 
/max