Re: [hibernate-dev] HV - Follow-Up: meta data API for method constraints
Hi guys,
I just created the pull request for HV-371:
https://github.com/hibernate/hibernate-validator/pull/35
Just one note on MethodDescriptor: getParameterTypes() was not even
necessary, as this information can be retrieved using
getParameterDescriptors().
This all was way more work than I had expected, but after all I think this
looks quite ok. In case you have any ideas for improvement, just let me
know. Otherwise I think we are ready for Beta2.
Gunnar
PS: Emmanuel, thanks for featuring Kevin's and my nomination for the
community awards on in.relation.to. Now we just need some more votes :)
2011/3/1 Gunnar Morling
> Alright, I'll change this then as proposed.
>
> 2011/3/1 Emmanuel Bernard
>
> Looks fine to me. I was concerned about passing Method around as well.
>>
>> On 1 mars 2011, at 00:29, Gunnar Morling wrote:
>>
>> Hi,
>>
>> 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). 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:
>>
>> * Retrieving method objects via the reflection APIs is somewhat nasty, in
>> particular it requires to handle a checked NoSuchMethodException:
>>
>> try {
>> Method bar = Foo.class.getDeclaredMethod( "bar", String.class );
>> }
>> catch(Exception e) {
>> throw new RuntimeException(e);
>> }
>>
>> * The handling in inheritance hierarchies with overridden/implemented
>> methods can be confusing to users not overly familiar with the reflection
>> API. In particular there are different method objects for a base method and
>> its implementation/overriding methods. This can be irritating when invoking
>> MethodDescriptor#getMethod() for instance.
>>
>> 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);
>> ...
>> }
>>
>> public interface MethodDescriptor extends ElementDescriptor {
>>
>> String getName();
>>
>> List> parameterTypes();
>> //instead of Method getMethod()
>> ...
>> }
>>
>> WDYT?
>>
>> Thanks, Gunnar
>>
>>
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] HV - Follow-Up: meta data API for method constraints
Awesome. I'll look at it asap. I am sure it is ok after all our discussions.
Getting ready for a release on Monday. Awesome work guys.
Sent from my HTC
- Reply message -
From: "Gunnar Morling"
Date: Sat, Mar 5, 2011 12:39
Subject: HV - Follow-Up: meta data API for method constraints
To: "Emmanuel Bernard" , "Hardy Ferentschik"
, "Kevin Pollet"
Cc:
Hi guys,
I just created the pull request for HV-371:
https://github.com/hibernate/hibernate-validator/pull/35
Just one note on MethodDescriptor: getParameterTypes() was not even
necessary, as this information can be retrieved using
getParameterDescriptors().
This all was way more work than I had expected, but after all I think this
looks quite ok. In case you have any ideas for improvement, just let me
know. Otherwise I think we are ready for Beta2.
Gunnar
PS: Emmanuel, thanks for featuring Kevin's and my nomination for the
community awards on in.relation.to. Now we just need some more votes :)
2011/3/1 Gunnar Morling
> Alright, I'll change this then as proposed.
>
> 2011/3/1 Emmanuel Bernard
>
> Looks fine to me. I was concerned about passing Method around as well.
>>
>> On 1 mars 2011, at 00:29, Gunnar Morling wrote:
>>
>> Hi,
>>
>> 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). 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:
>>
>> * Retrieving method objects via the reflection APIs is somewhat nasty, in
>> particular it requires to handle a checked NoSuchMethodException:
>>
>> try {
>> Method bar = Foo.class.getDeclaredMethod( "bar", String.class );
>> }
>> catch(Exception e) {
>> throw new RuntimeException(e);
>> }
>>
>> * The handling in inheritance hierarchies with overridden/implemented
>> methods can be confusing to users not overly familiar with the reflection
>> API. In particular there are different method objects for a base method and
>> its implementation/overriding methods. This can be irritating when invoking
>> MethodDescriptor#getMethod() for instance.
>>
>> 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);
>> ...
>> }
>>
>> public interface MethodDescriptor extends ElementDescriptor {
>>
>> String getName();
>>
>> List> parameterTypes();
>> //instead of Method getMethod()
>> ...
>> }
>>
>> WDYT?
>>
>> Thanks, Gunnar
>>
>>
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] org.hibernate.engine.jdbc.NonContextualLobCreator
Since master relies on jdk 1.6 (JDBC 4) I am thinking we should go ahead and make non-contextual LOB creation return concrete implementations as opposed to jdk proxies. The only real argument I see is *potentially* future proofing against JDBC 5 Thoughts? --- Steve Ebersole http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
