Hi, 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 ReturnValueConstraintViolation * 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. Gunnar 2010/10/4 Gunnar Morling <gunnar.morl...@googlemail.com> > 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 > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
