[bv-dev] Marker to trigger method validation

[Gunnar Morling]

2012/8/27 Emmanuel Bernard <emmanuel at hibernate.org>:
> Gunnar,
>
> We have been discussing whether or not `@MethodValidated` should be be present to trigger validation or not.
> Do we have a JIRA issue that capture that discussion?

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.

>
> My current feeling is the following:
>
> - we should propose that if the annotation is not present, method validation is performed for params and return value with the `Default` group

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.

> - if someone wants to override either the group or the validation mode, it must use `@MethodValidated`.

Seems reasonable.

>
> I also would like to be stronger and enforce the inheritance rules. Why did we decide to makes them simple recommendations? Any specific use case?

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.

>
> http://beanvalidation.org/latest-draft/spec/#validationapi-triggeringmethodvalidation
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev