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

no +1 because that means manual bootstrapping behaves differently even if> cdi is available and it's required to use an implementation which is> specific to a cdi >implementation< (or a custom one).

+0.5 for option 3, since that's what myfaces codi and others are doing already. no +1 because that means manual bootstrapping behaves differently even if cdi is available and it's required to use an implementation which is specific to a cdi >implementation< (or a custom one). regards, gerhard 2012/1/6 Emmanuel Bernard <emmanuel(a)hibernate.org&gt; > > I have updated the various options in the website > http://beanvalidation.org/proposals/BVAL-238/ > > I tend to like option 3 best at the moment. So is Pete Muir the CDI spec > lead. I've also verified a few things with him and left opened a few > questions in the EE - CDI -BV area. > > Thanks for all this feedback. > > On 3 janv. 2012, at 20:25, Emmanuel Bernard wrote: > > > 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 > > > _______________________________________________ > 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