[bv-dev] Triggering method validation

[Emmanuel Bernard]

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