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

Gerhard Petracek gerhard.petracek at gmail.com
Wed Jan 4 05:13:15 EST 2012


hi hardy,

you won't get dependency injection support with manual bootstrapping (btw.
you would have to use the class of a >concrete< cdi implementation - and
that isn't portable).
with the service-loader approach a new method for ValidatorContext is also
optional.

regards,
gerhard



2012/1/4 Hardy Ferentschik <hardy at hibernate.org>

> 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.
> >
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20120104/71d60566/attachment.html 


More information about the beanvalidation-dev mailing list