Hi, I pushed a first rough draft for the method-level validation to GitHub at http://github.com/gunnarmorling/hibernate-validator/tree/method-level-preparations
Currently only validateParameter() is implemented, but it shows, where the journey could be going. The draft is implemented as outlined in my previous mail: * MethodConstraintViolation extends ConstraintViolation with two attributes "method" and "parameterIndex", which are always set * ConstraintViolation#rootBean and propertyPath are set relative to any parameter annotated with @Valid, otherwise they are null The test at http://github.com/gunnarmorling/hibernate-validator/blob/method-level-preparations/hibernate-validator/src/test/java/org/hibernate/validator/test/engine/methodlevel/MethodLevelValidationTest.java should give you an impression. Validation is triggered by a dynamic proxy/invocation handler in the test. I think I'll have a look at the property path stuff next. I'm still not sure, whether the path API is the right thing to represent parameters. Using annotations for parameter names is a good idea, but as you said it should be optional. Method-level validation should not require name annotations. Gunnar 2010/9/29 Emmanuel Bernard <emman...@hibernate.org> > 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
