Re: [bv-dev] Triggering method validation

imo we should also talk with other expert-groups about the basic idea.

imo we should also talk with other expert-groups about the basic idea.

regards, gerhard 2012/1/27 Hardy Ferentschik <hardy(a)hibernate.org&gt; > > Thanks Gunnar for the explanation. It made things much clearer (at least

> Maybe my confusion was also caused by the fact that @ValidateGroups was

> generically named. I don't think it really expresses its intend.

> @MethodValidated be better? > > --Hardy > > > On Jan 26, 2012, at 9:29 PM, Gunnar Morling wrote: > > > 2012/1/26 Hardy Ferentschik <hardy(a)hibernate.org&gt;: > > > >> 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

> >>> if so delegate that validation to BV. > >> > >> Right. My understanding was that if method level validation is

> >> framework and method level annotations exist, validation gets

> > > > 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

> >>> > >>> @ValidateGroups({Group1.class, Group2.class}) > >>> public class OrderService { > >>> > >>> @NotNull > >>> public Order placeOrder((a)NotNull(groups=Group1.class)

> >>> max=20) String customerCode, @NotNull Item item, @Min(1) int

> >>> { //... } > >>> > >>> } > >> > >> 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

> >> > >> That is probably the solution I had in mind from the beginning. Seems

> > > > 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

> > > > 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(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > > > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev