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

Right. Historically in 1.0, we have always made sure to have stellar integration with EE but keep the integration points open to other technologies. That's why i'm trying to push for a solution that is both perfect in EE 7 and works nicely for other DIs. That gives headaches but it's worth it :) On 4 janv. 2012, at 13:22, Gerhard Petracek wrote: you are right in case of a java-ee6 application server (however e.g. with openwebbeans it's up to you if you add the plugin with the corresponding producers). however, before we continue we might have to think again about the original issue. the original topic is: dependency injection support e.g. for ConstraintValidator implementations. to be more concrete: dependency injection via @Inject (= jsr330 which is also the basis for other containers like spring and google guice). -> if we are just discussing cdi support, we can just specify that directly - e.g. a cdi implementation has to provide a ConstraintValidatorFactory which has to query the bean-manager -> we are done. that would mean: - no support of other dependency injection containers (= no pure jsr330 support) - manual bootstrapping behaves differently (even if cdi,... would be available) regards, gerhard 2012/1/4 Emmanuel Bernard <emmanuel(a)hibernate.org&gt; > You mean somebody with an application having the following producer will > conflict with the proposal. > > ``` > @Produces > ValidatorFactory produceValidatorFactory() {...} > //or > @Produces > Validator produceValidator() {...} > ``` > > Is that correct? I am a bit surprised though. Validator and > ValidatorFactory are already provided by CDI 1.0 so I imagine a non > qualified producer like the on atop would already conflict. Am I right? > > On 4 janv. 2012, at 12:18, Gerhard Petracek wrote: > > that's possible as well (for sure - e.g. myfaces codi (bv-module) already > provides such producers), but it can cause compatibility issues with > existing applications > (it won’t be an issue with myfaces codi because it uses a qualifier, but > it will be an issue with applications which have to switch from bv 1.0 to > 1.1 and have producers without a qualifier). > if we agree on it, we should think about a config entry to deactivate the > producer (it would trigger an invocation of ProcessAnnotatedType#veto for > the producer). > > in any case: it's still restricted to cdi. > > regards, > gerhard > > > > 2012/1/4 Emmanuel Bernard <emmanuel(a)hibernate.org&gt; > >> Gerhard pointed out a mistake. I mean @Produces or a producer generally. >> There is no such thing as a @Provider annotation. >> >> I've got a tangential question. Does CDI have a way to let libraries >> self declare producers like that? Obviously the BV jar won't be scanned and >> won't contain a bean.xml? >> >> >> On 4 janv. 2012, at 11:19, Emmanuel Bernard wrote: >> >> The point of Hardy (and Gunnar) is that in a DI environment, the >> Validator(Factory) lifecycle would most likely be handled by the DI >> framework and thus that the DI could provide proper injected instance to >> the BV bootstrap. I have to admit I had not completely seen it that way. >> >> The BV spec / RI could provide the portable CDI @Provider that >> implements this logic. For other DIs, they will need to be responsible for >> it. >> >> We will see how that plays but in a few ways it requires the DI >> environment to be aware of the content of validation.xml, we need to >> prototype that to see if that works well. >> >> On 4 janv. 2012, at 11:13, Gerhard Petracek wrote: >> >> hi hardy, >> >> you won't get dependency injection support with manual bootstrapping >> (btw. you would have to use the class of a >concrete< cdi implementation - >> and that isn't portable). >> with the service-loader approach a new method for ValidatorContext is >> also optional. >> >> regards, >> gerhard >> >> >> >> 2012/1/4 Hardy Ferentschik <hardy(a)hibernate.org&gt; >> >>> Hi, >>> >>> I prefer option 3 for its simplicity and the fact that it does not >>> change the current bootstrap API. >>> As you already say, integration is completely managed by the CDI-side >>> in which case I don't see why it >>> CDI could not manage MessageInterpolator and TraversableResolver as >>> well. >>> >>> I also think that Gunnar has a point that introducing InstanceProvider >>> creates some confusion with >>> the existing API. I also agree that CDI should know about BV, but not >>> the other way around. >>> >>> --Hardy >>> >>> >>> >>> On Jan 3, 2012, at 8:25 PM, Emmanuel Bernard wrote: >>> > #### Option 1: Add a Method to inject the BeanManager instance on >>> Bean Validation bootstrap sequence >>> > >>> > One approach would be to let the container set a `BeanManager` >>> instance >>> > >>> > ValidatorFactory factory = Validation >>> > .byDefaultProvider() >>> > .configure() >>> > .cdiBeanManager(beanManager) >>> > .buildValidatorFactory(); >>> > >>> > However that would add a hard dependency between CDI and Bean >>> Validation which is probably not welcomed. >>> > >>> > An alternative is to use an untyped version (which should probably be >>> favored): >>> > >>> > >>> > ValidatorFactory factory = Validation >>> > .byDefaultProvider() >>> > .configure() >>> > // T cdiBeanManager(Object beanManager) //raises an >>> exception if that's not a BeanManager >>> > .cdiBeanManager(beanManager) >>> > .buildValidatorFactory(); >>> > >>> > >>> > vs >>> > >>> > ValidatorFactory factory = Validation >>> > .byDefaultProvider() >>> > .configure() >>> > //raises an exception if that's not a BeanManager >>> > .addObject(Validation.CDI_BEAN_MANAGER, beanManager) // T >>> addObject(String key, Objet value) >>> > .buildValidatorFactory(); >>> > >>> > I however feel chagrined that the nicely typed `Configuration` API >>> requires such untyped approach. >>> > (I don't think introducing CdiBeanManagerFactory solves any issue, is >>> that true?). >>> > >>> > >>> > - have an untyped version of the above proposal >>> > - offer a generic `Map<String,Object> addObject(String key, Object >>> value)` method on `Configuration` >>> > >>> > #### Option 2: Use CDI facility to retrive the current `BeanManager` >>> > >>> > CDI exposes `BeanManager` via JNDI in EE, we could use it. >>> > >>> > Also CDI 1.1 offers programmatic lookup via the CDI class, see EDR1 >>> spec for details. >>> > <http://docs.jboss.org/cdi/spec/1.1.EDR1/html/spi.html#provider> >>> > >>> > #### Option 3: Ask CDI to inject a CDI aware >>> `ConstraintValidatorFactory` when creating the `ValidatorFactory` object >>> > >>> > Another idea would be to integrate BV/CDI via a CDI-aware >>> `ConstraintValidatorFactory` to be provided by CDI runtimes: >>> > >>> > ValidatorFactory factory = Validation >>> > .byDefaultProvider() >>> > .configure() >>> > .constraintValidatorFactory( new >>> CdiAwareConstraintValidatorFactory( beanManager ) ) >>> > .buildValidatorFactory(); >>> > >>> > That way the integration is completely managed by the CDI-side. >>> `Validator` and `ValidatorFactory` are already >>> > built-in beans in CDI so this wouldn't add much complexity. >>> > The CDI runtime would use this factory whenever a `Validator` or >>> `ValidatorFactory` is retrieved. >>> > >>> > #### Option 4: Add a method accepting an `InstanceProvider` >>> implementation in Bean Validation's bootstrap >>> > >>> > ValidatorFactory factory = Validation >>> > .byDefaultProvider() >>> > .configure() >>> > .instanceProvider(cdiInstanceProvider) >>> > .buildValidatorFactory(); >>> > >>> > public interface InstanceProvider { >>> > public <T> T createInstance(Class<T> type); >>> > public destroyInstance(Object instance); >>> > } >>> > >>> > The default implementation can be the no-arg constructor we have >>> today. 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. >>> > >>> > This option works fine as long as we don't require more complex >>> object creation logic. >>> > >>> >>> >>> _______________________________________________ >>> 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 >> >> >> _______________________________________________ >> 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 >> >> > _______________________________________________ > 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 > > _______________________________________________ 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