[bv-dev] BVAL-238 Dependency injection in ConstraintViolation
Gerhard Petracek
gerhard.petracek at gmail.com
Fri Jan 6 13:54:50 EST 2012
+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 at hibernate.org>
> 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.orgrepo?
> >>
> >>> 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 at hibernate.org>:
> >>> 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 at hibernate.org>:
> >>>>> 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/proposals/BVAL-238.md). 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 at lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >>>>>
> >>>>
> >>>> _______________________________________________
> >>>> beanvalidation-dev mailing list
> >>>> beanvalidation-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >>>
> >>>
> >>> _______________________________________________
> >>> beanvalidation-dev mailing list
> >>> beanvalidation-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >>>
> >>
> >> _______________________________________________
> >> beanvalidation-dev mailing list
> >> beanvalidation-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >
> >
> > _______________________________________________
> > beanvalidation-dev mailing list
> > beanvalidation-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20120106/e85f4fa8/attachment-0001.html
More information about the beanvalidation-dev
mailing list