[hibernate-dev] [Validator] method level validation

[Hardy Ferentschik]

Hi,

forwarding this email to hibernate-dev to get some more feedback.

Here are some of my thoughts. The method level validation is suggested in  
Appendix C of the Bean Validation specification. The method signatures  
there all return a set of ConstraintViolations.
The question is how binding these signatures are.

Root bean and property path are indeed questionable for method level  
validation. By extending ConstraintViolation you still have to deal with  
these values. Maybe instead of
extending we should have a new interface MethodConstraintViolation.

Emmanuel, do you have some more feedback on what was discussed regarding  
appendix C?

--Hardy

------- Forwarded message -------
From: "Gunnar Morling" <gunnar.morling at googlemail.com>
To: "Hardy Ferentschik" <hibernate at ferentschik.de>

while working on method-level validation I wondered how to represent the  
failing validation of method parameters. I think  
javax.validation.ConstraintViolation in its current form is only partly  
suitable for the needs of parameter/return value validation:

* The concept of property path seems not to fit right. How would the  
property path look for a failing parameter constraint? One could come up  
with something like "MyBean.MyMethod(String,Int).Parameters[1]" but I  
can't say I'd like that
  * The concept of a root bean does only fit partly. I think one would need  
a safe reference to the "root method" and the parameter index. A direct  
reference to the class hosting the validated method seems only partly  
useful (and could anytimes be retrieved from a Method reference).

I therefore prototyped this into this direction:

* Created a MethodConstraintViolation that extends ConstraintViolation by  
adding fields the causing method and the parameter index (one surely would  
add a flag or something in case of return value validation)
  * In case a constraint directly at one of a method's parameters fail,  
ConstraintViolation#rootBean and propertyPath are null (but method and  
parameterIndex are set)
* In case a "cascading" constraint fails (meaning in this context, a  
parameter is annotated with @Valid and the referenced bean has constraints  
itself which in turn fail), method and parameterIndex are set, rootBean  
and propertyPath refer to parameter bean itself, *not* the class hosting  
the validated method

WDYT, is this the right way to go? Maybe we should brainstorm a bit on IRC?