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

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.

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.

We should however let people provide `MessageInterpolator` and `TraversableResolver` implementation classes.

Hi all, First of all happy new year to everyone. I wish you the best for 2012. I have spend some time to hammer the last details of BVAL-238. I would like your feedback on how CDI should be integrated with Bean Validation and whether or not we facilitate other DI solutions. Below is a copy of the discussion as provided on the website at http://beanvalidation.org/proposals/BVAL-238/ (look for "How is CDI BeanManager (or equivalent) injected into Bean Validation?". Please provide any comment, I'd like to settle this asap and move forward. That's the last big open question IMO before I apply these changes to the spec. Thanks Emmanuel --- ### How is CDI `BeanManager` (or equivalent) injected into Bean Validation? I'm assuming CDI exposes the ability to instantiate and destroy CDI beans via a `BeanManager` interface. #### 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. #### Which option? Option 1 has many drawbacks and should be avoided. Option 2 is the easiest solution but puts CDI above other DI technologies. This is not bad per se but that's a point. Option 3 is quite elegant as most of the time CDI is responsible for the lifecycle of `ValidatorFactory` and can interject in the bootstrap process. When `ValidatorFactory` is created manually, we can ask the user to use a provider specific `CdiAwareConstraintValidatorFactory`. My main concern with option 3 is whether or not we (will) need access to CDI's `BeanManager` to handle the lifecycle of other objects in the Bean Validation universe. `MessageInterpolator` and `TraversableResolver` could also benefit from CDI. Note that these examples do not create objects, they are objects. Option 4 tries to address the shortcomings of option 3 provided we keep the simple object creation logic. It has my preference so far. #### How would injection of `MessageInterpolator` and `TraversableResolver` be solved? 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. We should however let people provide `MessageInterpolator` and `TraversableResolver` implementation classes that will be used to ask for a CDI bean instance (like `ConstraintValidator` are resolved). Suggestions? On 24 oct. 2011, at 22:26, Gunnar Morling wrote: >> What you're saying is that assuming @ValidatorFactory is injected in EE or SE, it is the CDI responsibility to set the right ConstraintValidatorFactory. We can consider this approach definitely. Can you add it as an alternative in the website page? > > Sure. Can you provide me with write access for the beanvalidation.org repo? > >> Note that CDI strategy is to let other specs describe their integration, we are responsible for describing how that will work. > > I see. Validator and ValidatorFactory are built-in beans in CDI 1.0 > already, so I think one could extend on that and require that the > runtime must use a CDI-enabled ConstraintValidatorFactory. Maybe this > is something which we could contribute to CDI 1.1. > > It would be interesting to know how CDI integration is solved for JPA > entity listeners. Do you have any information on that? > > > 2011/10/24 Emmanuel Bernard <emmanuel(a)hibernate.org&gt;: >> There are a couple of reasons why I proposed this approach. Of course nothing i settled. >> >> - IFAIR, BeanManager was to be responsible from the creation and destruction of the object. We do have a hook for creation but not for destruction yet. So it's likely that ConstraintValidatorfactory needs to be enhanced >> - I was trying to facilitate the work of the container or the "SE" container. >> >> What you're saying is that assuming @ValidatorFactory is injected in EE or SE, it is the CDI responsibility to set the right ConstraintValidatorFactory. We can consider this approach definitely. Can you add it as an alternative in the website page? >> >> Note that CDI strategy is to let other specs describe their integration, we are responsible for describing how that will work. >> >> Emmanuel >> >> On 22 oct. 2011, at 10:51, Gunnar Morling wrote: >> >>> Hi, >>> >>> concerning "How is CDI BeanManager (or equivalent) injected into Bean >>> Validation?" I'm wondering whether we really require something like >>> cdiBeanManager(). >>> >>> Couldn't the CDI runtime just set a CDI-aware >>> ConstraintValidatorFactory when creating the Validator(Factory). We >>> then wouldn't have any dependency to CDI in BV at all. On the downside >>> this would mean CDI-enabled validators would only work when using a >>> validator managed by CDI but not using a validator retrieved via >>> Validation.buildDefaultValidatorFactory() but that would be ok IMO. >>> >>> So generally I think the BV/CDI integration should be more >>> triggered/managed from the CDI side than the other way around. >>> >>> --Gunnar >>> >>> >>> 2011/10/21 Emmanuel Bernard <emmanuel(a)hibernate.org&gt;: >>>> Hi team, >>>> I've been thinking about BVAL-238 and came up with a first round of ideas and open questions. >>>> It is available here http://beanvalidation.org/proposals/BVAL-238/ >>>> >>>> Please give me your feedback. I think this issue can be closed quite quickly. >>>> >>>> I've also created a proposals section on the website that will contain such work in progress proposals before inclusion in the spec proper. Check out http://beanvalidation.org/proposals >>>> >>>> On a side note, for casual website editing, you can use GitHub's `Edit this file` button (see https://github.com/beanvalidation/beanvalidation.org/blob/master/proposal... ). It's not quite a wiki but that's pretty close. One thing you cannot do is create a new file unfortunately. Anyone that have asked for write access should see this button. >>>> >>>> Emmanuel >>>> _______________________________________________ >>>> 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