[bv-dev] Triggering method validation

[Hardy Ferentschik]

@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