Another connected subject is about the extension that would enable method validation.

Again, we can take the idea of having this extension implemented by all bv providers or simply as an outside extension hosted in apache deltaspike or as an independent HV module.

If all providers implement this extension, then we need a way to detect that an extension has already added an interceptor. A possible solution is ask the extension to use the same marker annotation to attach the interceptor. That would require the marker annotation to be in the BV SPI which I am not a big fan of (pollution) and we need to make sure this does not force the annotation to depend (even at compile time) on CDI => needs to be investigated

Otherwise, the extension is built as followed, it looks for each bean and detect if any of its method is a constrained method. If true then the interceptor is added. Otherwise the bean is left untouched (performance). The BV metadata calls are described in the spec (pull request #15).

There are two camps in the method validation war

1. ease-of-users

Emmanuel and others in the EE group are in favor of an implicit method validation provided that the method is constrained. No need to explicitly add an annotation or an option.
The pros are ease of use. Nothing is activated unless the methods are constrained but it is a bit magic esp in the CDI extension.

2. Expliciters

Hardy particularly is in favor of asking the user to explicitly add an annotation to enable method validation for a given bean. It feels less magic and is more aligned to the spirit of CDI according to Hardy. It comes with an additional burden on the user's shoulders and possibly more complex rules wrt to this annotation inheritance.

The subject need to be addressed by the EG and the community at large.