[hibernate-dev] HV-376

[Emmanuel Bernard]

Hi,

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).
WDYT?
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.

yep.

> 
> 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.

BTW
MethodDescriptor#getMethod
why is it required? I think we've discussed that but I forgot.