[bv-dev] Triggering method validation

[Emmanuel Bernard]

Yes I think it does. though one has to call 

    getConstrainedMethods().size() != 0 || getConstrainedConstructors().size()

to know if a bean is to be intercepted. Probably not to bad as constructors and method interceptions could be done with entirely different mechanisms.

On 29 janv. 2012, at 14:31, Gunnar Morling wrote:

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