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.

> #2 Define an annotation such as @javax.validation.ValidateGroups within BV > >       @ValidateGroups({Group1.class, Group2.class}) >       public class OrderService { > >               @NotNull >               public Order placeOrder((a)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?

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

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

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(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 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((a)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(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

@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(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 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((a)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(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

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(a)hibernate.org&gt;: > @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(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 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((a)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(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 > > > _______________________________________________ > 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

IMO the annotation has to most importantly make the difference between Bean and method validation clear. @ValidateConstraints doesn't. On Jan 27, 2012, at 4:18 PM, 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? _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

Hi experts, I'm in the middle of writing a proposal document for BVAL-241 (method validation), which I'm planning to put up for discussion within the next days. One item for which I'd like to gather some feedback beforehand is how to trigger method validation. I think we all agree that BV itself should only provide the API and meta-model for method validation, but it shouldn't actually trigger a validation of method level constraints. 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. The following options were mentioned at some time: #1 Use @Valid This would be semantically wrong IMO. @Valid is only a marker for cascaded validation, but it shouldn't cause a validation itself. #2 Define an annotation such as @javax.validation.ValidateGroups within BV @ValidateGroups({Group1.class, Group2.class}) public class OrderService { @NotNull public Order placeOrder((a)NotNull(groups=Group1.class) @Size(min=3, max=20) String customerCode, @NotNull Item item, @Min(1) int quantity) { //... } } This annotation could be discovered by interceptors/proxies etc. which then would trigger a validation of the method constraints. The method could be defined on a class level as well as on method level (with the latter having precedence in case of conflicts). We could surely define such an annotation and specify it semantics, but I'm unsure how that would actually work out with technologies using that feature. 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. #3 Don't define anything related in BV, leave that completely to integrators CDI could define a proper interceptor binding annotation, others could use some XML based configuration etc. Personally I think we could go for #2 and define an annotation to be used by integrators (e.g. by checking for the annotation, Spring might define a related point cut etc.). We would recommend to trigger validation based on this annotation where possible and hopeful would cover most cases that way. Integrators would still be free to define their own means of triggering a validation if required. Any thoughts? Are there any other alternatives? --Gunnar _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

> Note that we also need some API to tell whether or not a method or any method on a given class are intercepted. That would allow to optimize the activation or not of an interceptor. The BV-241 proposal contains an extension to the meta-data API [1]. Does that cover what you have in mind? --Gunnar [1] http://beanvalidation.org/proposals/BVAL-241/#meta_data 2012/1/27 Emmanuel Bernard <emmanuel(a)hibernate.org&gt;: > Note that we also need some API to tell whether or not a method or any method on a given class are intercepted. That would allow to optimize the activation or not of an interceptor. > > My natural preference goes for #2 but we need to verify that > > 1. it works nicely with other EE JSRs like CDI, JAX-RS, JSF. Any other? > 2. alternative technologies can use that (Spring Framework, Guice etc > > On 22 janv. 2012, at 20:33, Gunnar Morling wrote: > >> Hi experts, >> >> I'm in the middle of writing a proposal document for BVAL-241 (method >> validation), which I'm planning to put up for discussion within the >> next days. >> >> One item for which I'd like to gather some feedback beforehand is how >> to trigger method validation. I think we all agree that BV itself >> should only provide the API and meta-model for method validation, but >> it shouldn't actually trigger a validation of method level >> constraints. >> >> 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. >> >> The following options were mentioned at some time: >> >> #1 Use @Valid >> >> This would be semantically wrong IMO. @Valid is only a marker for >> cascaded validation, but it shouldn't cause a validation itself. >> >> #2 Define an annotation such as @javax.validation.ValidateGroups within BV >> >> @ValidateGroups({Group1.class, Group2.class}) >> public class OrderService { >> >> @NotNull >> public Order placeOrder((a)NotNull(groups=Group1.class) @Size(min=3, >> max=20) String customerCode, @NotNull Item item, @Min(1) int quantity) >> { //... } >> >> } >> >> This annotation could be discovered by interceptors/proxies etc. which >> then would trigger a validation of the method constraints. The method >> could be defined on a class level as well as on method level (with the >> latter having precedence in case of conflicts). >> >> We could surely define such an annotation and specify it semantics, >> but I'm unsure how that would actually work out with technologies >> using that feature. 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. >> >> #3 Don't define anything related in BV, leave that completely to integrators >> >> CDI could define a proper interceptor binding annotation, others could >> use some XML based configuration etc. >> >> Personally I think we could go for #2 and define an annotation to be >> used by integrators (e.g. by checking for the annotation, Spring might >> define a related point cut etc.). We would recommend to trigger >> validation based on this annotation where possible and hopeful would >> cover most cases that way. Integrators would still be free to define >> their own means of triggering a validation if required. >> >> Any thoughts? Are there any other alternatives? >> >> --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