(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&gt; 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 >