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

Emmanuel Bernard emmanuel at hibernate.org
Wed Jan 4 06:34:04 EST 2012


You mean somebody with an application having the following producer will conflict with the proposal.

```
@Produces
ValidatorFactory produceValidatorFactory() {...}
//or
@Produces
Validator produceValidator() {...}
```

Is that correct? I am a bit surprised though. Validator and ValidatorFactory are already provided by CDI 1.0 so I imagine a non qualified producer like the on atop would already conflict. Am I right?

On 4 janv. 2012, at 12:18, Gerhard Petracek wrote:

> 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
> 
> 
> _______________________________________________
> 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/b08dd5cd/attachment-0001.html 


More information about the beanvalidation-dev mailing list