3:45 a.m.
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?