Re: [bv-dev] BVAL-238 Dependency injection in ConstraintViolation
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 :)