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

[Emmanuel Bernard]

On 4 janv. 2012, at 00:07, Gunnar Morling wrote:

> Hi,
> 
> option #4 sounds promising to me.
> 
> Though I'm seeing some potential for confusion about the existence of
> ConstraintValidatorFactory *and* InstanceProvider. Wouldn't actually
> the latter suffice? After all CVF is in it's current form only a
> special kind of instance provider for validators, while
> InstanceProvider implementations would create all type of BV objects,
> be it validators, interpolators etc. So maybe we should deprecate CVF
> when introducing InstanceProvider?

Good point. Priority rules might become hairy but you are correct, we should deprecate ConstraintValidatorFactory and give InstanceProvider precedence in this situation.

> 
> Regarding the name createInstance(): I'd find getInstance()
> preferable. Depending on the given bean's lifecycle it might not be
> newly created but an existing instance might be returned by the
> instance provider.

I was expecting to retrieve only dependent objects from InstanceProvider:

- ConstraintValidator are dependent objects (at least unless we go for your alternative approach - which I'm a bit reluctant of today)
- MessageREsolver and TraversableResolver can easily be dependent objects and rely on injected objects from other scopes

Do you see this as a problem? The alternative would be to alter the contract to pass a flag when we mandate a dependent object. 

Thoughts?

> 
>> 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.
> 
> +1 For letting CDI provide a CDIInstanceProvider. The CDI spec today
> already knows about BV but not the other way around, and I think we
> should strive to keep it that way. There shouldn't be a circular
> dependency between the specs.

Gunnar that's not going to happen. Pete told me that their goal is to externalize CDI integration to each spec rather than gather all logic in the CDI spec. We might even have to provide the provider implementations. If that's your only argument for this approach it's not strong enough.

> 
>> If instances are provided, we could still let CDI do setter-style `inject()`ion. constructor injection won't work. But it seems to me it's preferable to *not* do any injection on provided instances.
> 
> +1 for *not* injecting beans provided by the user via the bootstrap
> API. If someone provides an interpolator for instance he should be
> knowing what he is doing (after all the provided bean could be a CDI
> bean already).

Right, my line of thoughts exactly.

> 
>> We should however let people provide `MessageInterpolator` and `TraversableResolver` implementation classes.
> 
> This would only happen via the XML configuration, right? In that case
> the InstanceProvider would create the beans and perform the injection
> (via CDI in case of the CDIInstanceProvider).

No. I don't want to give XML a special privilege. So I am entertaining the idea of have a programmatic way to pass such a class. What do you think?
Arguing against myself, if someone wants to programmatically build a ValidatorFactory in a DI environment, he will likely get the MessageResolver and TraversalResolver from the DI by injection in his provider and do the wiring there?

What do you all think?