<p>> imo we should also talk with other expert-groups about the basic idea.</p>
<p>Absolutely. Emmanuel/I had already some discussions with folks from the CDI and JAX-RS EGs.</p>
<p>JSF is definitely a good point, I hadn't considered that so far. Do you know who would be good to talk to?</p>
<p>Am 27.01.2012 12:54 schrieb "Gerhard Petracek" <<a href="mailto:gerhard.petracek@gmail.com">gerhard.petracek@gmail.com</a>>:<br>
><br>
> hi @ all,<br>
><br>
> imo we should also talk with other expert-groups about the basic idea.<br>
> e.g. the jsf-eg (i'm going to propose group-validation triggered via command components (based on a feature of myfaces extval) and maybe they have additional ideas related to this topic.)<br>
><br>
> regards,<br>
> gerhard<br>
><br>
><br>
><br>
><br>
> 2012/1/27 Hardy Ferentschik <<a href="mailto:hardy@hibernate.org">hardy@hibernate.org</a>><br>
>><br>
>> Thanks Gunnar for the explanation. It made things much clearer (at least for me).<br>
>> Maybe my confusion was also caused by the fact that @ValidateGroups was so<br>
>> generically named. I don't think it really expresses its intend. Wouldn't something like<br>
>> @MethodValidated be better?<br>
>><br>
>> --Hardy<br>
>><br>
>><br>
>> On Jan 26, 2012, at 9:29 PM, Gunnar Morling wrote:<br>
>><br>
>> > 2012/1/26 Hardy Ferentschik <<a href="mailto:hardy@hibernate.org">hardy@hibernate.org</a>>:<br>
>> ><br>
>> >> On Jan 22, 2012, at 8:33 PM, Gunnar Morling wrote:<br>
>> >>> Instead this should be task of technologies integrating the method<br>
>> >>> validation feature to decide whether a validation is needed or not and<br>
>> >>> if so delegate that validation to BV.<br>
>> >><br>
>> >> Right. My understanding was that if method level validation is enabled in the integrating<br>
>> >> framework and method level annotations exist, validation gets triggered.<br>
>> ><br>
>> > Yepp, I think there are different interpretations of "enabling method<br>
>> > validation" floating around which might cause some irritations. There<br>
>> > are actually two "levels" of enablement IMO:<br>
>> ><br>
>> > * A system is generally able to make use of method validation by<br>
>> > providing the required integration layer. Taking CDI for example,<br>
>> > there would be a CDI method interceptor which is able to intercept<br>
>> > method calls and invoke Validator#validateParameters() and/or<br>
>> > Validator#validateReturnValue().<br>
>> > * Based on that integration layer, method validation is actually<br>
>> > enabled (or not) for given types. In other words instead of enabling<br>
>> > method validation globally for all types/methods, I think often a more<br>
>> > fine-grained configurability is required. Sticking to the CDI example,<br>
>> > the types to perform method validation on, would be annotated with an<br>
>> > interceptor binding annotation which causes the validation interceptor<br>
>> > to kick in if methods on the annotated type are invoked. Taking Spring<br>
>> > AOP as example, the types for which to perform method validation on<br>
>> > could be specified using an advice with type name patterns,<br>
>> > restrictions to certain packages etc.<br>
>> ><br>
>> >>> #2 Define an annotation such as @javax.validation.ValidateGroups within BV<br>
>> >>><br>
>> >>> @ValidateGroups({Group1.class, Group2.class})<br>
>> >>> public class OrderService {<br>
>> >>><br>
>> >>> @NotNull<br>
>> >>> public Order placeOrder(@NotNull(groups=Group1.class) @Size(min=3,<br>
>> >>> max=20) String customerCode, @NotNull Item item, @Min(1) int quantity)<br>
>> >>> { //... }<br>
>> >>><br>
>> >>> }<br>
>> >><br>
>> >> What would @ValidateGroups in this case do?<br>
>> ><br>
>> > @ValidateGroups would be the second "enabler" from the two above. That<br>
>> > is, it controls that method validation shall be performed on the<br>
>> > methods of OrderService by means of the validation interceptor<br>
>> > provided by the given integration layer. It would also control which<br>
>> > groups should be validated for methods invoked on the annotated type<br>
>> > (here Group1 and Group2). It furthermore might control whether to<br>
>> > perform a parameter or return value validation or both.<br>
>> ><br>
>> > This is comparable to declarative transaction control; there exists an<br>
>> > interceptor which is able to begin/commit transactions. To which<br>
>> > types/operations this interceptor applies can be controlled using an<br>
>> > annotation such as @Transactional (or other means such as an XML<br>
>> > config).<br>
>> ><br>
>> >>> #3 Don't define anything related in BV, leave that completely to integrators<br>
>> >><br>
>> >> That is probably the solution I had in mind from the beginning. Seems still most reasonable to me.<br>
>> ><br>
>> > That's definitely an option, but it might cause a proliferation of the<br>
>> > JEE platform. There are several potential integrators of method<br>
>> > validation (I know at least about CDI and JAX-RS). They could all<br>
>> > define their own variant of @ValidateGroups, but these would likely be<br>
>> > very similar to each other. So another option is to define one<br>
>> > standardized annotation for that purpose in BV which then can be used<br>
>> > by all interested integrators. For instance<br>
>> ><br>
>> > * JAX-RS would check for that annotation on REST resource classes and<br>
>> > would invoke j.v.Validator upon invocation of resource methods<br>
>> > * CDI would define a CDI method interceptor and handle the annotation<br>
>> > as interceptor binding annotation which causes the interceptor to kick<br>
>> > in using the standard CDI mechanisms for interceptor handling<br>
>> ><br>
>> >>> 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.<br>
>> ><br>
>> > In between I had the chance to talk to Pete from the CDI EG. He<br>
>> > confirmed that annotation types can programmatically be "promoted" to<br>
>> > interceptor binding annotations. That means CDI could integrate with<br>
>> > an annotation type defined in the BV API also if that type hasn't the<br>
>> > @InterceptorBinding meta annotation (which it shouldn't IMO in order<br>
>> > to avoid a compile dependency from BV to CDI).<br>
>> ><br>
>> > --Gunnar<br>
>> ><br>
>> > _______________________________________________<br>
>> > beanvalidation-dev mailing list<br>
>> > <a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>
>> > <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
>><br>
>><br>
>> _______________________________________________<br>
>> beanvalidation-dev mailing list<br>
>> <a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> beanvalidation-dev mailing list<br>
> <a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
></p>