On 8/14/2013 3:08 PM, Farah Juma wrote:
I recently worked on CDI and Bean Validation integration for method validation
(WFLY-529). As described in , part of this work involved replacing the delegate of the
EE LazyValidatorFactory with a CDI-enabled ValidatorFactory. However, JCA and JPA still
currently use copied versions of the old EE LazyValidatorFactory. Since JCA and JPA should
also have access to the CDI-enabled ValidatorFactory, it would be good if we could remove
the copies (i.e., remove JCAValidatorFactory and JPALazyValidatorFactory) and use the
current EE LazyValidatorFactory directly instead. As discussed with Scott Marlow, for JPA,
it looks like we can access the EE LazyValidatorFactory from the deployment unit
attachment (i.e., via
deploymentUnit.getAttachment(BeanValidationAttachments.VALIDATOR_FACTORY)), as described
in WFLY-1705 . However, for JCA, it doesn't seem like this will be possible since
the code that currently instantiates the JCAValidatorFactory doesn't have access to
tUnit (and it seems like there isn't a way to modify the code to be able to access
this). Another option might be to register the ValidatorFactory as a service and then
perform a manual lookup on the service.
I was wondering if anyone had any thoughts about what approach to take for JCA or how to
go about removing the JCAValidatorFactory. I've created WFLY-1882  to track this.
In addition to JCA and JPA, we'll need to consider what should be done for JSF since
it will also need to be able to access the CDI-enabled ValidatorFactory. Note that JSF
doesn't use a copy of the EE LazyValidatorFactory and so it seems to be bootstrapping
Bean Validation in another way.
JSF bootstraps Bean Validation as per JSF spec section 18.104.22.168:
*The Bean Validation ValidatorFactory is the main entry point into Bean
Validation and is responsible for creating**
**Validator instances. [P1-start-validatoryfactory]A ValidatorFactory is
retrieved using the following algorithm:**
**If the servlet context contains a ValidatorFactory instance under the
**javax.faces.validator.beanValidator.ValidatorFactory, this instance is
used by JSF to acquire Validator instances**
**(specifically in the BeanValidator). This key should be defined in the
constant named VALIDATOR_FACTORY_KEY**
**If the servlet context does not contain such an entry, JSF looks for a
Bean Validation provider in the classpath. If**
**present, the standard Bean Validation bootstrap strategy is used. If
not present, Bean Validation integration is**
In our case, we use the second method, which is to simply place the Bean
Validation provider in the classpath. For every deployment that uses JSF,
the JSF subsystem will add the org.hibernate.validator module to the
Thanks for that info, that's very helpful. The problem we're trying to
solve is making sure that Bean Validation and CDI are properly integrated
as required by the BV spec. For instance CDI-based dependency injection
must be available to constraint validator implementations.
The validator factory maintained in the WildFly EE module (which e.g. is
available via JNDI) provides this functionality as it is configured as
necessary during bootstrap. A validator factory obtained via the standard
BV bootstrap strategy won't offer this functionality, though.
So based on what you say, one solution for the JSF case could be to make
the VF from the EE module available in the servlet context, e.g. by
retrieving it via JNDI (assuming the order of loading the modules allows
for that). I'm not sure though about a WAR deployment which is CDI-enabled.
Is the EE module activated in this case?
wildfly-dev mailing list