[hibernate-dev] [Validator] method level validation
gunnar.morling at googlemail.com
Thu Nov 18 14:26:35 EST 2010
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 at 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
More information about the hibernate-dev