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

Gunnar Morling gunnar.morling at googlemail.com
Sat Jan 7 06:41:47 EST 2012


> 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).
I think it might be a good idea to let CDI define a built-in bean of
type j.v.ConstraintValidatorFactory (similar to
j.v.Validator(Factory), see CDI spec. 3.7). Then one could have the
CVF injected into managed beans which need to manually bootstrap a
Validator(Factory) without having to know the provider specific
implementation:

public class MyBean {

    @Inject
    private ConstraintValidatorFactory cvf;

    public void foo() {
        Validator v = Validation.byDefaultProvider().configure()
            .constraintValidatorFactory( cvf )
            .traversableResolver( new MyFancyResolver() )
            .buildValidatorFactory()
            .getValidator();

        v.validate(...);
    }
}

This leaves the case open where one is an unmanaged environment (and
hence can't get the CVF injected) but wants to construct a CDI-enabled
Validator. Personally I don't think this is a common scenario.

--Gunnar

2012/1/6 Gerhard Petracek <gerhard.petracek at gmail.com>:
> +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.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 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
>
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>



More information about the beanvalidation-dev mailing list