Hi,
I recently worked on CDI and Bean Validation integration for method validation (WFLY-529).
As described in [1], 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 [2]. 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
the deploymentUnit (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 [3] 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.
[1]
https://issues.jboss.org/browse/WFLY-529?focusedCommentId=12787076&pa...
[2]
https://issues.jboss.org/browse/WFLY-1705
[3]
https://issues.jboss.org/browse/WFLY-1882
Thanks,
Farah