This issue can't be edited
Because it belongs to an archived project. Jira admins can restore projects from the archive.
Provide additional, including custom variables, for message interpolation
Description
Environment
Attachments
Activity
Gunnar Morling February 7, 2013 at 7:36 PMEdited
Rene, as of Bean Validation 1.1 you'll be able to refer to the validated value within your message templates using the EL expression ${validatedValue}.
Rene Grob October 5, 2011 at 7:47 PM
The issue referenced also needs extended message interpolation support. May be it also needs a call context in order to pass the userId. Every bit of information that is provided to the ConstraintValidator should also be available in the message interpolator since that input could be necessary the format a meaningful error message. While the validator just lacks of a call context, the message interpolator should may be split up in sub-components with a clearer responsibility (E.g. interpolating the message template, resolving resource files, resolving variables (placeholders)) This could also ease the integration in other frameworks.
Hardy Ferentschik October 4, 2011 at 3:47 PM
Related thread on the Hibernate Validator Forum - https://forum.hibernate.org/viewtopic.php?f=9&t=1012886
Rene Grob September 27, 2011 at 8:21 PM
Well a ClassLoaderService is specific and clear but only solve one particular problem while a call context is more flexible but less explicit.What kind of object should be passed with the call. A generic Map or something more explicit while still extensible? May be internally a Map or Object array could be used but externally a certain Interface or Key has to be used to access it.
However resolving resources is probably a thing that does not need to be decided per call and therefore can be configured in the validation factory.
Note about the call context: The same problem exists for JPA entity listeners: You cannot pass the current user or other call specific context to the entity listener. There are a lot of workarounds in the web using a ThreadLocal variable to emulate this missing parameter. That's not what JEE should be teaching us...
Emmanuel Bernard September 27, 2011 at 5:25 PM
Also note that the Glassfish team would have a need for the Bean class to be passed as well in order to load the right message bundle.
http://wikis.sun.com/display/GlassFish/GlassFish+Bean+Validation+Error+Message+Internationalization
The payload approach does not sound right but passing in the context the bean class is. Or even better should there be a ClassLoaderService?
I'm using the Hibernate Validators since the day it got released. I wrote some extensions which also might be useful to other users:
I extended the MessageInterpolator so that I can use the rootBean, leafBean and the invalidValue in the message templates. Further I added support for nested properties. Here are some samples for (extended) message templates:
=>
While this information is unnecessary while you are typing the data and see the whole record, it might be essential if the input is a file and the message is written to a log.
It would also useful to provide some custom properties in the MessageInterpolator context:
=>
While the leafBean is available as validatedValue in the MessageInterpolator.Context, I had to extend the context to provide the other values.
The validator has only access to the validated object and the annotation. It is not always possible and reasonable to set the context information on the validated object. It would be good to have some context available in the validator. Now I pass the context information through a ThreadLocal variable which is very ugly and error prone. E.g. a validator could check if a value is equal to an entry of a dynamic list which depends on the context.
Sometimes it would be useful to pass some context to the validator:
Of course time consuming validation should not be triggered too often. A constaint causing such a validation would typically not define the Default.class group.
See also:
http://relation.to/Bloggers/JSRBeanVali ... mment19490
Regards René