[hibernate-dev] HV-376

Emmanuel Bernard emmanuel at hibernate.org
Mon Feb 7 05:09:28 EST 2011


On 6 févr. 2011, at 20:57, Gunnar Morling wrote:

> one other issue we might/should deliver for Beta2 is http://opensource.atlassian.com/projects/hibernate/browse/HV-371 ("Support method-level constraints in meta-data API"), at least API-wise. I pushed a first draft to https://github.com/gunnarmorling/hibernate-validator/tree/HV-371 and would be happy on your feedback.
> With some exceptions this is pretty similar to what is suggested in Appendix C. As we can't alter the BeanDescriptor type, I created a new type TypeDescriptor (I think the name is better anyways, as constraints are no longer restricted to bean-style types with the advent of method validation). This type resembles BeanDescriptor (it doesn't inherit for the naming reason but I would let me convince if you think it should) and is returned by MethodValidator#getConstraintsForType(). 

It seems that in the grand scheme of BV 1.1, we would put all your methods back on BeanDescription without necessarily adding a new type. I initially thought of adding TypeDescriptor as a superclass of BeanDescriptor but the idea of having the noting of properties on TypeDescriptor felt wrong (in Java).
If we all agree then that means TypeDescriptor is really a (temporary) subclass of BeanDescriptor

> Anything else is pretty much straight forward. Currently it is not possible to determine from which exact method version in a hierarchy a certain constraint originates (using the ConstraintFinder API one can only find out, whether a constraint is defined locally or *somewhere* up in the hierarchy). Do you think this would be needed? I think, the same restriction holds for the existing property descriptor API.

I've always envisioned that one in need to find where a constraint was exactly would use a combination of lookingAt(LOCAL_ELEMENT) and clazz.getSuperclass().
What would be the use case for reaching the exact method straight?

> The existing methods (getElementClass(), getConstraintDescriptors() etc.) on ElementDescriptor all seem to make sense for the new descriptor types. For MethodDescriptor they should relate to the return value type/constraints, for ParameterDescriptor to the parameter type/constraints.


> WDYT, should we ship this as API in Beta2 for public review and implement it with the next milestone? I'm also CC-ing Emmanuel as I think he originally wrote Appendix C.

Fine by me, it's up to you guys. The design is very much inline with the original design of Bean Validation.

why is it required? I think we've discussed that but I forgot.

More information about the hibernate-dev mailing list