4:13 a.m.
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev