[hibernate-dev] [Validator] method level validation

[Gunnar Morling]

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 <emmanuel at 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.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.