Re: [hibernate-dev] [Validator] method level validation

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(a)googlemail.com&gt; > To: "Hardy Ferentschik" <hibernate(a)ferentschik.de&gt; > > 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.