[ http://opensource.atlassian.com/projects/hibernate/browse/HV-44?page=com.... ] Emmanuel Bernard commented on HV-44: ------------------------------------ You can do that with a custom MessageInterpolator implementation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HV-44?page=com.... ] Olle Hallin commented on HV-44: ------------------------------- I checked the MessageInterpolator interface. The default interpolator is fine. I just want to inject another Locale to ClassValidator. That's all. IMHO it is *much* simpler if ClassValidator.java replaces the two calls to Locale.getDefault() with LocaleHolder.getLocale(), provided that the following class exists: package org.hibernate.validator; import java.util.Locale; public class LocaleHolder { private static ThreadLocal localeHolder = new InheritableThreadLocal(); public static void setLocale(Locale locale) { localeHolder.set(locale); } public static Locale getLocale() { Locale locale = (Locale)localeHolder.get(); return locale == null ? Locale.getDefault() : locale; } } Benefits: 1) Configuration-free 2) Simple 3) Efficient 4) Backwards compatible -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HV-44?page=com.... ] Olle Hallin commented on HV-44: ------------------------------- I don't follow. Explain! Which JEE rule forbids the use of ThreadLocal? In what circumstances does this break the JEE contract? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HV-44?page=com.... ] Olle Hallin commented on HV-44: ------------------------------- I have no problems with that different requests are processed by different threads, be it servlet or ejb requests. What I want is to reuse the Hibernate Validator InvalidMessages in the web layer. This is done automatically by Tapestry5. The problem is that not all web users are happy with my web server's default locale, and I don't have a desire to do surgery on neither tapestry-hibernate.jar nor hibernate-core.jar in order to inject my custom MessageInterpolator. I can easily make sure that a ThreadLocal is set early in *each* servlet request though. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HV-44?page=com.... ] Olle Hallin commented on HV-44: ------------------------------- Forget about Tapestry for this discussion. Take JBoss Seam as another example of multi-lingual web framework. Quote from Hibernate Validator Reference Manual (http://www.hibernate.org/hib_docs/validator/reference/en/html/validator-c...) <h:form> <div> <h:messages/> </div> <s:validateAll> <div> Country: <h:inputText value="#{location.country}" required="true"/> </div> <div> Zip code: <h:inputText value="#{location.zip}" required="true"/> </div> <div> <h:commandButton/> </div> </s:validateAll> </h:form> the Seam <s:validateAll> tag is supposed to execute Hibernate Validator and present error messages in the sessions locale (according to the Seam 2.0 ref manual). I've read the code of ClassValidator and *MessageInterpolator, and I cannot see how this could work without applying serious amounts of application code to bypass the inherent single-language design of ClassValidator. Perhaps this is the value that Seam adds. I might write a spike to test if it is so ;-) Servlet-only (i.e., no ejb), multi-lingual web apps with Hibernate-persisted pojos is a very common use case. Be it Tapestry, Seam, Spring MVC, Wicket, Struts or whatever presentation layer. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HV-44?page=com.... ] Hayo Schmidt commented on HV-44: -------------------------------- I would like to emphasize the need for a resolution to this topic. The requirement to set the language in hibernate validator has been put on me. There should be a new constructor: public ClassValidator(Class<T> beanClass, Locale locale) Also there is another bug with setting the language: new ClassValidator<ModAssignBean>( myBean.class, ResourceBundle.getBundle("org.hibernate.validator.resources.DefaultValidatorMessages", Locale.ENGLISH) ); should load the english resource bundle from the delivered set of resources. It does not, because there is no english resource DefaultValidatorMessages_en.properties in the library. The default is in english, but you cannot load it, unless you are on an english system. A workaround for this is copying DefaultValidatorMessages.properties to another place as ValidatorMessages_en.properties and the load the resource from there. But you have to check this file on every update of hibernate-validator, which is a potential cause for bugs. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HV-44?page=com.... ] Olle Hallin commented on HV-44: ------------------------------- EJB applications suffer from the same single-language problem as a servlet-only app: not all EJB clients want the validation error messages in the EJB container's default locale. Replace EJB with any remoting technology and this is still true; SOAP, RMI, REST, ... So the client must pass the locale to the service somehow, which then makes it known to HibernateValidator. And then we are back to my proposed solution: Each thread that uses Hibernate Validator is responsible for making the locale known to Hibernate Validator. And the easiest possible way of doing this is IMHO to use a ThreadLocal. No custom message interpolator is needed. In a servlet-only architecture, the web browser acts as client and sets the Accept-Locale HTTP header. The servlet is the service that sets the ThreadLocal. When remoting is involved (incl. local EJBs), the servlet must pass the Locale to the next thread, which also sets the ThreadLocal and so on ad infinitum. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HV-44?page=com.... ] Jean-Christian Gagné commented on HV-44: ---------------------------------------- I would make 2 suggestions : 1) Create new methods in ClassValidator, adding a Locale parameter to all getInvalidValues(...). 2) I agree that custom config may be neccessary to introduce a Locale resolving strategy, but providing its own MessageInterpolator is not a simple solution for a not-so-unusual problem. So I suggest to introduce a simple LocaleResolver interface in Hibernate validator configuration, with default returning Locale.getDefault(). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira