[bv-dev] Triggering method validation

Gunnar Morling gunnar.morling at googlemail.com
Sun Jan 29 08:31:10 EST 2012


> 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 at hibernate.org>:
> 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(@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 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



More information about the beanvalidation-dev mailing list