Re: [bv-dev] Marker to trigger method validation

2012/8/27 Emmanuel Bernard <emmanuel(a)hibernate.org&gt;: The idea behind @MethodValidated was that this is something which we provide for integrators of method validation, while those would have to define the specific runtime semantics (e.g. is method validation enabled by default etc.). Based on the latest discussions with the Java EE EG, I think what we would have to describe within the BV spec would be the specific behavior for Java EE/CDI. Is that what you had in mind? I've created https://hibernate.onjira.com/browse/BVAL-305 as sub-task of BVAL-272 for this. So you mean to enable method validation by default for any CDI bean, EJB, MDB etc.? I'm wondering whether there may be performance implications for cases where no validation is needed/wanted. I guess implementations could optimize the case where no constraint annotations are present at a method, but it's still an interceptor involved for each method invocation. Another question would also be how to disable validation globally if that's needed. All in all I find atm. an opt-in approach slightly more appealing then the other way around. Seems reasonable. The idea behind this was that we can't control all integrators and there possibilities/conventions. If e.g. the interceptor mechanism of a particular DI container has a class over method precedence rule, any validation interceptor for this container should adhere to this convention IMO instead of something defined by us. Of course we can and probably should define the behavior for Java EE.