3:50 a.m.
(Adding the JBoss AS Dev list)
## JNDI and injection
I think a portable extension is not a problem when it comes to adding Validator and
ValidatorFactory as injectable components. There is no performance issue here.
For JNDI, the problem is that other components access JNDI to get a reference to
ValidatorFactory before CDI is started, so I envisioned something like that:
- the container adds a LazyValidatorFactory/LazyValidator to JNDI
- when CDI starts and the Hibernate Validator portable extension runs, the correct
ValidatorFactory is created and passed to the LazyValidatorFactory as target for the
delegation. That way all components have access to the CDI enabled version.
## Method validation and interceptor binding
That is where performance is crucial. We need a special code or a custom portable
extension that makes use of the jandex information to find for a given deployment:
- all types directly or indirectly involved with @Valid, @Constraint and
@ValidateOnExecution
- all constrained types as defined in XML
- all subtypes of these types
- filter them according to the list of CDI beans
And add interception to these CDI beans assuming they are properly constrained according
to the BV rules.
Emmanuel
On 4 avr. 2013, at 08:43, Gunnar Morling <gunnar(a)hibernate.org> wrote:
All,
I'd like to get a discussion started on the integration of Hibernate Validator and
CDI when running on AS.
To give some background, the Bean Validation 1.1 spec defines an integration of BV and
CDI:
* Validator and ValidatorFactory are considered managed beans retrievable via @Inject
* Constraint validators are considered managed beans and thus subject to dependency
injection
* Any managed bean methods with BV constraints on parameters or return value are
validated automatically upon invocation using an interceptor
To satisfy these requirements, we have implemented a CDI portable extension in HV 5 which
registers beans for validator and factory, sets up the method interceptor etc.
I've got the following questions:
1) Should this PE used on AS to integrate BV and CDI? If so, IIRC there were problems
with PEs contained in AS modules, but I think these should have been fixed in between.
Jozef?
I also remember someone thinking about more efficient means of doing the task based on
Weld-specific APIs instead of the standardized CDI APIs used by the PE.
2) The CDI-enabled validator (factory) must be retrievable via JNDI and EE's
@Resource injection. Based on my (not overly deep) understanding of how things work in AS,
the registration process currently looks like this:
a) The validator factory is created using
LazyValidatorFactory/BeanValidationFactoryDeployer, bound to JNDI and attached to the
current deployment
b) WeldDeploymentProcessor picks it up from there and makes it available to Weld using
the ValidationServices SPI
AFAICS step a) could be used for non-CDI-enabled deployments. For CDI-enabled
deployments, the VF created by the PE (assuming it's going to be used) would have to
be registered. So I guess the following could be done:
* Make step a) register the VF only for non-CDI-enabled deployments
* For CDI-enabled deployments, bind the VF from the PE to JNDI e.g. in
WeldDeploymentProcessor (or create a new deployment unit processor for this). I'm not
sure though whether beans can already be retrieved from Weld at this point during
deployment.
This is just a rough idea based on my current understanding, I'm looking forward for
your thoughts and ideas how the task should be accomplished.
Thanks,
--Gunnar