[bv-dev] Triggering method validation

Emmanuel Bernard emmanuel at hibernate.org
Fri Jan 27 10:33:54 EST 2012


A constructor is a method that returns an instance of the object. The fact that the Java reflection API disagree does not change that fact.
That being said, how will we do ctor validation in CDI?

On 27 janv. 2012, at 16:18, Gunnar Morling wrote:

> One potential issue I see here is that "method validation" can also be
> applied to constructors.
> 
> One aspect of this is wording in the spec. There we should IMO have a
> preamble saying something like "method level validation can refer to
> methods and constructors." Another thing is the annotation name we're
> trying to find. Something like @ValidateMethods suggests IMO that no
> constructor validation is performed, or at least leaves room for
> interpretation.
> 
> So maybe @ValidateConstraints?
> 
> Generally I think adjectives make better binding annotation names
> (@Transactional being a good example) instead of imperative names like
> the ones discussed so far. In Seam Validation it's hence named
> @AutoValidating. That's surely not perfect, too, but maybe someone has
> another idea based on that?
> 
> --Gunnar
> 
> 2012/1/27 Hardy Ferentschik <hardy at hibernate.org>:
>> @ValidateMethodCall,
>> 
>> but any of these three would work for me
>> 
>> --Hardy
>> 
>> On Jan 27, 2012, at 3:25 PM, Emmanuel Bernard wrote:
>> 
>>> @ValidateMethods
>>> @ValidateOnMethodCall
>>> ?
>>> 
>>> On 27 janv. 2012, at 12:13, Hardy Ferentschik wrote:
>>> 
>>>> Thanks Gunnar for the explanation. It made things much clearer (at least for me).
>>>> Maybe my confusion was also caused by the fact that @ValidateGroups was so
>>>> generically named. I don't think it really expresses its intend. Wouldn't something like
>>>> @MethodValidated be better?
>>>> 
>>>> --Hardy
>>>> 
>>>> 
>>>> On Jan 26, 2012, at 9:29 PM, Gunnar Morling wrote:
>>>> 
>>>>> 2012/1/26 Hardy Ferentschik <hardy at hibernate.org>:
>>>>> 
>>>>>> On Jan 22, 2012, at 8:33 PM, Gunnar Morling wrote:
>>>>>>> Instead this should be task of technologies integrating the method
>>>>>>> validation feature to decide whether a validation is needed or not and
>>>>>>> if so delegate that validation to BV.
>>>>>> 
>>>>>> Right. My understanding was that if method level validation is enabled in the integrating
>>>>>> framework and method level annotations exist, validation gets triggered.
>>>>> 
>>>>> Yepp, I think there are different interpretations of "enabling method
>>>>> validation" floating around which might cause some irritations. There
>>>>> are actually two "levels" of enablement IMO:
>>>>> 
>>>>> * A system is generally able to make use of method validation by
>>>>> providing the required integration layer. Taking CDI for example,
>>>>> there would be a CDI method interceptor which is able to intercept
>>>>> method calls and invoke Validator#validateParameters() and/or
>>>>> Validator#validateReturnValue().
>>>>> * Based on that integration layer, method validation is actually
>>>>> enabled (or not) for given types. In other words instead of enabling
>>>>> method validation globally for all types/methods, I think often a more
>>>>> fine-grained configurability is required. Sticking to the CDI example,
>>>>> the types to perform method validation on, would be annotated with an
>>>>> interceptor binding annotation which causes the validation interceptor
>>>>> to kick in if methods on the annotated type are invoked. Taking Spring
>>>>> AOP as example, the types for which to perform method validation on
>>>>> could be specified using an advice with type name patterns,
>>>>> restrictions to certain packages etc.
>>>>> 
>>>>>>> #2 Define an annotation such as @javax.validation.ValidateGroups within BV
>>>>>>> 
>>>>>>>     @ValidateGroups({Group1.class, Group2.class})
>>>>>>>     public class OrderService {
>>>>>>> 
>>>>>>>             @NotNull
>>>>>>>             public Order placeOrder(@NotNull(groups=Group1.class) @Size(min=3,
>>>>>>> max=20) String customerCode, @NotNull Item item, @Min(1) int quantity)
>>>>>>> { //... }
>>>>>>> 
>>>>>>>     }
>>>>>> 
>>>>>> What would @ValidateGroups in this case do?
>>>>> 
>>>>> @ValidateGroups would be the second "enabler" from the two above. That
>>>>> is, it controls that method validation shall be performed on the
>>>>> methods of OrderService by means of the validation interceptor
>>>>> provided by the given integration layer. It would also control which
>>>>> groups should be validated for methods invoked on the annotated type
>>>>> (here Group1 and Group2). It furthermore might control whether to
>>>>> perform a parameter or return value validation or both.
>>>>> 
>>>>> This is comparable to declarative transaction control; there exists an
>>>>> interceptor which is able to begin/commit transactions. To which
>>>>> types/operations this interceptor applies can be controlled using an
>>>>> annotation such as @Transactional (or other means such as an XML
>>>>> config).
>>>>> 
>>>>>>> #3 Don't define anything related in BV, leave that completely to integrators
>>>>>> 
>>>>>> That is probably the solution I had in mind from the beginning. Seems still most reasonable to me.
>>>>> 
>>>>> That's definitely an option, but it might cause a proliferation of the
>>>>> JEE platform. There are several potential integrators of method
>>>>> validation (I know at least about CDI and JAX-RS). They could all
>>>>> define their own variant of @ValidateGroups, but these would likely be
>>>>> very similar to each other. So another option is to define one
>>>>> standardized annotation for that purpose in BV which then can be used
>>>>> by all interested integrators. For instance
>>>>> 
>>>>> * JAX-RS would check for that annotation on REST resource classes and
>>>>> would invoke j.v.Validator upon invocation of resource methods
>>>>> * CDI would define a CDI method interceptor and handle the annotation
>>>>> as interceptor binding annotation which causes the interceptor to kick
>>>>> in using the standard CDI mechanisms for interceptor handling
>>>>> 
>>>>>>> Taking CDI for example, AFAIK the annotation would have to be annotated with the @InterceptorBinding meta annotation. I don't know whether/how it would be possible that we define the "basic" annotation, while integrators "enrich" it with the meta data they require.
>>>>> 
>>>>> In between I had the chance to talk to Pete from the CDI EG. He
>>>>> confirmed that annotation types can programmatically be "promoted" to
>>>>> interceptor binding annotations. That means CDI could integrate with
>>>>> an annotation type defined in the BV API also if that type hasn't the
>>>>> @InterceptorBinding meta annotation (which it shouldn't IMO in order
>>>>> to avoid a compile dependency from BV to CDI).
>>>>> 
>>>>> --Gunnar
>>>>> 
>>>>> _______________________________________________
>>>>> beanvalidation-dev mailing list
>>>>> beanvalidation-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>> 
>>>> 
>>>> _______________________________________________
>>>> beanvalidation-dev mailing list
>>>> beanvalidation-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>> 
>>> 
>>> _______________________________________________
>>> beanvalidation-dev mailing list
>>> beanvalidation-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> 
>> 
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> 
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev




More information about the beanvalidation-dev mailing list