[hibernate-dev] [Validator] method level validation

[Emmanuel Bernard]

Hey guys, 
Good analysis, see my comments inline.

On 27 sept. 2010, at 12:02, Hardy Ferentschik wrote:

> 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

MyBean.myMethod(String,Integer, Address)#2.street1
MyBean.myMethod(String,Integer, Address)#return.street1
We can fix the string representation later but could the property Path API support what you want?

> * 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)

The subclass looks like the best approach I can think of.
Not a fan of the flag for the return type but I guess that makes sense.
parameter index: I wonder if we should introduce an optional named parameter annotation to make things nicer.

> * 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)

you don't have access to the rootBean? In the Java platform, you receive null if you're calling a static method, otherwise you get the object instance.
If we want to stay consistent, I think getPropertyPath should return a Path containing a Node describing the method and a node describing the parameter.

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

I get where you are going. I wonder if dedicated methods in the new subclass would be better. I would say so. ie a dedicated getParameterValue()

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

We can discuss on IRC but when developing BV, I wrote a lot of API prototypes to see which one felt the best.

I've just pushed a copy of the API, TCK and Hibernate Validator projects to GitHub which will make it easy to share prototypes.
The simplest approach is to create a user account over there and fork.
http://github.com/beanvalidation/api
http://github.com/beanvalidation/tck
http://github.com/emmanuelbernard/hibernate-validator

Make sure to create a dedicated branch for each prototype.