[bv-dev] Triggering method validation

[Emmanuel Bernard]

@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