I'm writing this mail to give a short summary of a meeting on the method
level validation feature for HV Emmanuel and I had yesterday. Basically
there are not too many changes to what has previously been in discussion
(see below). We agreed upon the following things to be probably useful:
* The type hosting the method at which's parameter or return value a
constraint violation occured should be marked as the root bean in resulting
ConstraintViolation instances. Previously I thought this not to be a good
idea but I rather changed my mind as this seems consistent , if we also do
the following points:
* There should be dedicated path Node derivations to describe a
method/parameter/return value which would have all the specific required
attributes (e.g. parameter index). That way we can create a semantically
useful property path for the constraint violation.
* MethodConstraintViolation from the current prototype should probably be
decomposed into ParameterConstraintViolation and
* The issues related to the meta data API (a potential ParameterDescriptor
interface etc.) should at least be investigated before shipping the method
validation feature in order to be sure not to hinder the development of the
meta data stuff in a meaningful way possibly later on.
I'll continue on the prototyp based on that input and hopefully will have
something to show in the near future. Any comments are warmly welcome.
2010/10/4 Gunnar Morling <gunnar.morling(a)googlemail.com>
I pushed a first rough draft for the method-level validation to GitHub at
Currently only validateParameter() is implemented, but it shows, where the
journey could be going. The draft is implemented as outlined in my previous
* 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
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