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).