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

[Emmanuel Bernard]

On 4 janv. 2012, at 23:38, Gunnar Morling wrote:

>> 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.
> I'm not sure. MessageResolver implementations for instance might well
> be stateless and hence long living (singleton) beans. Of course we
> might just specify that only dependent objects might be returned by
> InstanceProvider. I'm just a little bit concerned about creating lot's
> of beans which were actually not required. I think if we allow non
> dependent objects we must require BV providers to not keep references
> to them longer then necessary.
> 
> How would the flag look like you're mentioning?

T getInstance(Class<T> type, Scope scope);

enum Scope {
    DEPENDENT,
    AUTO
}

But I'm not a big fan of this approach.

>>> 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?
> 
> But using a programmatic API, would one pass classes for interpolator
> et al. or instances? I'd expect the latter. In that case XML still
> would be the only scenario where classes (or class names) are
> specified, requiring BV to instantiate the beans.

If we allow classes to be provided programmatically, it would be

interface Configuration<T extends Configuration<T>> {
    T messageResolver(MessageResolver resolver);
    T messageResolverClass(Class<? extends MessageResolver> resolverClass);
}

The advantage is that we handle the object instantiation inhouse instead of leaving that to the caller. The inconvenient is that we handle the object instantiation inhouse :)