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.morl...@googlemail.com> > To: "Hardy Ferentschik" <hibern...@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. _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
