[hibernate-dev] HV - Follow-Up: meta data API for method constraints

Hardy Ferentschik hibernate at ferentschik.de
Tue Mar 1 05:55:59 EST 2011


On Tue, 01 Mar 2011 00:29:49 +0100, Gunnar Morling  
<gunnar.morling at googlemail.com> wrote:

> I pretty much finished the implementation of the meta data API related to
> method level constraints for Hibernate Validator (see
> https://github.com/gunnarmorling/hibernate-validator/commits/HV-371).

Looks great. I added a few line comments to some of the commits.

> The implementation conforms with what we currently discussed, but right  
> now I'm wondering whether exposing java.lang.reflect.Method on the API  
> is actually a good idea. I see two issues:

> Therefore I would be interested in feedback on the following change:

> public interface TypeDescriptor extends ElementDescriptor {
>     MethodDescriptor getConstraintsForMethod(String name, Class<?>...  
> parameterTypes);
>
>     //instead of MethodDescriptor getConstraintsForMethod(Method method);
> }

I like it. To get hold of the method you need the method name and  
parameter types anyways. So
we are saving the user some reflection code. And in case he really has a  
Method instance it is easy
enough to extract the parameter. Just wondering about the case where the  
method does not exist.
In the current TypeDescriptorTest you are throwing a  
IllegalArgumentException for null or if the
method is not a method for the current type. If we switch to your new  
proposal I think we should throw
a MethodNotFoundException

> public interface MethodDescriptor extends ElementDescriptor {
>     String getName();
>     List<Class<?>> parameterTypes();
>     //instead of Method getMethod()
> }

+1

I don't see any major problems with this approach. In contrary it seems to  
solve some ambiguities.

--Hardy



More information about the hibernate-dev mailing list