Good analysis, see my comments inline.
On 27 sept. 2010, at 12:02, Hardy Ferentschik wrote:
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
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?
------- Forwarded message -------
From: "Gunnar Morling" <gunnar.morling(a)googlemail.com>
To: "Hardy Ferentschik" <hibernate(a)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" but I can't say I'd like
We can fix the string representation later but could the property Path API support what
* 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.
Make sure to create a dedicated branch for each prototype.