[bv-dev] BVAL-238 Dependency injection in ConstraintViolation

Hardy Ferentschik hardy at hibernate.org
Wed Jan 4 04:54:14 EST 2012


Hi,

I prefer option 3 for its simplicity and the fact that it does not change the current bootstrap API. 
As you already say,  integration is completely managed by the CDI-side in which case I don't see why it
CDI could not manage MessageInterpolator and TraversableResolver as well.

I also think that Gunnar has a point that introducing InstanceProvider creates some confusion with 
the existing API. I also agree that CDI should know about BV, but not the other way around.

--Hardy



On Jan 3, 2012, at 8:25 PM, Emmanuel Bernard wrote:
> #### Option 1: Add a Method to inject the BeanManager instance on Bean Validation bootstrap sequence
> 
> One approach would be to let the container set a `BeanManager` instance
> 
>    ValidatorFactory factory = Validation
>        .byDefaultProvider()
>        .configure()
>            .cdiBeanManager(beanManager)
>         .buildValidatorFactory();
> 
> However that would add a hard dependency between CDI and Bean Validation which is probably not welcomed.
> 
> An alternative is to use an untyped version (which should probably be favored):
> 
> 
>    ValidatorFactory factory = Validation
>        .byDefaultProvider()
>        .configure()
>            // T cdiBeanManager(Object beanManager) //raises an exception if that's not a BeanManager
>            .cdiBeanManager(beanManager) 
>         .buildValidatorFactory();
> 
> 
> vs
> 
>    ValidatorFactory factory = Validation
>        .byDefaultProvider()
>        .configure()
>            //raises an exception if that's not a BeanManager
>            .addObject(Validation.CDI_BEAN_MANAGER, beanManager) // T addObject(String key, Objet value) 
>         .buildValidatorFactory();
> 
> I however feel chagrined that the nicely typed `Configuration` API requires such untyped approach.
> (I don't think introducing CdiBeanManagerFactory solves any issue, is that true?).
> 
> 
> - have an untyped version of the above proposal
> - offer a generic `Map<String,Object> addObject(String key, Object value)` method on `Configuration`
> 
> #### Option 2: Use CDI facility to retrive the current `BeanManager`
> 
> CDI exposes `BeanManager` via JNDI in EE, we could use it.
> 
> Also CDI 1.1 offers programmatic lookup via the CDI class, see EDR1 spec for details. 
> <http://docs.jboss.org/cdi/spec/1.1.EDR1/html/spi.html#provider>
> 
> #### Option 3: Ask CDI to inject a CDI aware `ConstraintValidatorFactory` when creating the `ValidatorFactory` object
> 
> Another idea would be to integrate BV/CDI via a CDI-aware `ConstraintValidatorFactory` to be provided by CDI runtimes:
> 
>    ValidatorFactory factory = Validation
>        .byDefaultProvider()
>        .configure()
>            .constraintValidatorFactory( new CdiAwareConstraintValidatorFactory( beanManager ) )
>        .buildValidatorFactory();
> 
> That way the integration is completely managed by the CDI-side. `Validator` and `ValidatorFactory` are already 
> built-in beans in CDI so this wouldn't add much complexity. 
> The CDI runtime would use this factory whenever a `Validator` or `ValidatorFactory` is retrieved.
> 
> #### Option 4: Add a method accepting an `InstanceProvider` implementation in Bean Validation's bootstrap
> 
>    ValidatorFactory factory = Validation
>        .byDefaultProvider()
>        .configure()
>            .instanceProvider(cdiInstanceProvider)
>         .buildValidatorFactory();
> 
>    public interface InstanceProvider {
>        public <T> T createInstance(Class<T> type);
>        public destroyInstance(Object instance);
>    }
> 
> The default implementation can be the no-arg constructor we have today. We can either ask CDI to 
> provide a `CDIInstanceProvider` at `ValidatorFactory` creation like in option 3 or make it the
> default implementation if CDI is present according to option 2.
> 
> This option works fine as long as we don't require more complex object creation logic.
> 




More information about the beanvalidation-dev mailing list