Decide how CDI and Bean Validation is integrated

+1 on the "Summary after the IRC discussion".

For the planned draft, we will start with the following:

• for the Validator injection: use option 1. each of the BV provider CDI extensions try and detect if the @Default Validator is registered

• for the interceptor extension: use option 1. ease-of-users

We should mention the alternative in the specification and will revisit those subjects.

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.

Summary after the IRC discussion

• there is today the notion of default provider which is either the one defined in XML or the first one returned by the resolver

• this default provider is returned by JNDI lookup, @Resource injection (EE) and @Inject in CDI

• we should keep that behavior (it's good and we must keep backward compatibility)

• a BV provider will provide a CDI extenstion that inject qualified Validator/ValidatorFactory (like @Inject @HibernateValidator Validator)

• each provider should offer its own qualifier

Then there are two options:

1. each of the BV provider CDI extensions try and detect if the @Default Validator is registered

• if registered nothing is done

• if not registered, then the extension is responsible to register the default Validator(Factory) according to the current rules of the specification on what the default provider is

2. a separate extension is responsible for adding the injection of the default Validator(Factory) according to the current rules of the specification on what the default provider is
This "default" extension could be hosted:

• in the Apache DeltaSpike project

• in Hibernate Validator as a separate module not depending on Hibernate Validator's code

A container can decide to use this default extension or implement the same logic in a proprietary way. The rules must be obeyed though wrt adding the default Validator(Factory). Note that in case 1. (not a separate extension), the container must add this injection before the other BV provider CDI extensions kick in.

In SE, adding the default extension would essentially offer the same level of support as the container. In case 1., this would be provided by the bv provider extension(s).

BTW adding an alias in CDI is very easy:

@Produces
public Validator defaultValidator(@Hibernate Validator validator) {
return validator;
}