[bv-dev] BVAL-238 Dependency injection in ConstraintViolation
Gerhard Petracek
gerhard.petracek at gmail.com
Wed Jan 4 06:18:31 EST 2012
that's possible as well (for sure - e.g. myfaces codi (bv-module) already
provides such producers), but it can cause compatibility issues with
existing applications
(it won’t be an issue with myfaces codi because it uses a qualifier, but it
will be an issue with applications which have to switch from bv 1.0 to 1.1
and have producers without a qualifier).
if we agree on it, we should think about a config entry to deactivate the
producer (it would trigger an invocation of ProcessAnnotatedType#veto for
the producer).
in any case: it's still restricted to cdi.
regards,
gerhard
2012/1/4 Emmanuel Bernard <emmanuel at hibernate.org>
> Gerhard pointed out a mistake. I mean @Produces or a producer generally.
> There is no such thing as a @Provider annotation.
>
> I've got a tangential question. Does CDI have a way to let libraries self
> declare producers like that? Obviously the BV jar won't be scanned and
> won't contain a bean.xml?
>
>
> On 4 janv. 2012, at 11:19, Emmanuel Bernard wrote:
>
> The point of Hardy (and Gunnar) is that in a DI environment, the
> Validator(Factory) lifecycle would most likely be handled by the DI
> framework and thus that the DI could provide proper injected instance to
> the BV bootstrap. I have to admit I had not completely seen it that way.
>
> The BV spec / RI could provide the portable CDI @Provider that implements
> this logic. For other DIs, they will need to be responsible for it.
>
> We will see how that plays but in a few ways it requires the DI
> environment to be aware of the content of validation.xml, we need to
> prototype that to see if that works well.
>
> On 4 janv. 2012, at 11:13, Gerhard Petracek wrote:
>
> 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
>>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
>
> _______________________________________________
> 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/a8e1f3f2/attachment.html
More information about the beanvalidation-dev
mailing list