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

> 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? >> +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. Ok, I wasn't aware that CDI tries to remove the BV integration from their side. This would changes things of course. In any case there should be a dependency between the specs in one way only IMO. A problem with BV knowing about CDI is how to make it co-exist with other DI solutions (as discussed in this thread). >> 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. --Gunnar 2012/1/4 Emmanuel Bernard <emmanuel(a)hibernate.org&gt;: > > 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? > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev