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

Gerhard Petracek gerhard.petracek at gmail.com
Wed Jan 4 08:31:43 EST 2012


+1 -> compared to the other suggestions: +1 for the service-loader approach
because it allows jsr330 support without the need to add a new method to
ValidatorContext as well as a new config entry and it's a std. java
mechanism.

regards,
gerhard



2012/1/4 Emmanuel Bernard <emmanuel at hibernate.org>

> Right. Historically in 1.0, we have always made sure to have stellar
> integration with EE but keep the integration points open to other
> technologies. That's why i'm trying to push for a solution that is both
> perfect in EE 7 and works nicely for other DIs. That gives headaches but
> it's worth it :)
>
> On 4 janv. 2012, at 13:22, Gerhard Petracek wrote:
>
> you are right in case of a java-ee6 application server (however e.g. with
> openwebbeans it's up to you if you add the plugin with the corresponding
> producers).
>
> however, before we continue we might have to think again about the
> original issue.
> the original topic is: dependency injection support e.g. for
> ConstraintValidator implementations.
> to be more concrete: dependency injection via @Inject (= jsr330 which is
> also the basis for other containers like spring and google guice).
>
> -> if we are just discussing cdi support, we can just specify that
> directly - e.g. a cdi implementation has to provide a
> ConstraintValidatorFactory which has to query the bean-manager -> we are
> done.
>
> that would mean:
>  - no support of other dependency injection containers (= no pure jsr330
> support)
>  - manual bootstrapping behaves differently (even if cdi,... would be
> available)
>
> regards,
> gerhard
>
>
>
> 2012/1/4 Emmanuel Bernard <emmanuel at hibernate.org>
>
>> 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
>>
>>
>>
>> _______________________________________________
>> 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/9e71edca/attachment-0001.html 


More information about the beanvalidation-dev mailing list