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

Gerhard Petracek gerhard.petracek at gmail.com
Thu Jan 5 08:13:11 EST 2012


if a constraint is more like a "marker", it's possible - e.g.
UniqueLoginName (because you just need the call of #isValid and #initialize
is empty).

even if you have state you can store it in an injected resource via
#initialize and get it back in #isValid.
i don't say that it is a nice approach and i think there aren't many users
who are doing it.
but i know projects which are doing that in combination with dependency
injection (@Inject in the constraint validator) which works due to a small
extension.

regards,
gerhard



2012/1/5 Emmanuel Bernard <emmanuel at hibernate.org>

> ConstraintValidator are not stateless mainly due to the initialize
> contract.
>
> On 5 janv. 2012, at 11:59, Gerhard Petracek wrote:
>
> there are just some specified restrictions concerning caching statefull bv
> artifacts.
> however, if e.g. a constraint validator is stateless (or the state is
> stored somewhere else), there isn't an issue.
> i've seen different working scenarios in combination with proxies for
> different bv artifacts.
>
> regards,
> gerhard
>
>
>
> 2012/1/4 Gunnar Morling <gunnar.morling at googlemail.com>
>
>> > I was expecting to retrieve only dependent objects from
>> InstanceProvider:>> - ConstraintValidator are dependent objects (at least
>> unless we go for your alternative approach - which I'm a bit reluctant of
>> today)> - MessageREsolver and TraversableResolver can easily be dependent
>> objects and rely on injected objects from other scopes>> Do you see this as
>> a problem? The alternative would be to alter the contract to pass a flag
>> when we mandate a dependent object.
>> I'm not sure. MessageResolver implementations for instance might well
>> be stateless and hence long living (singleton) beans. Of course we
>> might just specify that only dependent objects might be returned by
>> InstanceProvider. I'm just a little bit concerned about creating lot's
>> of beans which were actually not required. I think if we allow non
>> dependent objects we must require BV providers to not keep references
>> to them longer then necessary.
>>
>> How would the flag look like you're mentioning?
>>
>> >> +1 For letting CDI provide a CDIInstanceProvider. The CDI spec today
>> >> already knows about BV but not the other way around, and I think we
>> >> should strive to keep it that way. There shouldn't be a circular
>> >> dependency between the specs.
>> >
>> > Gunnar that's not going to happen. Pete told me that their goal is to
>> externalize CDI integration to each spec rather than gather all logic in
>> the CDI spec. We might even have to provide the provider implementations.
>> If that's your only argument for this approach it's not strong enough.
>>
>> Ok, I wasn't aware that CDI tries to remove the BV integration from
>> their side. This would changes things of course. In any case there
>> should be a dependency between the specs in one way only IMO. A
>> problem with BV knowing about CDI is how to make it co-exist with
>> other DI solutions (as discussed in this thread).
>> >> This would only happen via the XML configuration, right? In that case
>> >> the InstanceProvider would create the beans and perform the injection
>> >> (via CDI in case of the CDIInstanceProvider).
>> >
>> > No. I don't want to give XML a special privilege. So I am entertaining
>> the idea of have a programmatic way to pass such a class. What do you think?
>> > Arguing against myself, if someone wants to programmatically build a
>> ValidatorFactory in a DI environment, he will likely get the
>> MessageResolver and TraversalResolver from the DI by injection in his
>> provider and do the wiring there?
>>
>> But using a programmatic API, would one pass classes for interpolator
>> et al. or instances? I'd expect the latter. In that case XML still
>> would be the only scenario where classes (or class names) are
>> specified, requiring BV to instantiate the beans.
>>
>> --Gunnar
>>
>> 2012/1/4 Emmanuel Bernard <emmanuel at hibernate.org>:
>> >
>> > On 4 janv. 2012, at 00:07, Gunnar Morling wrote:
>> >
>> >> Hi,
>> >>
>> >> option #4 sounds promising to me.
>> >>
>> >> Though I'm seeing some potential for confusion about the existence of
>> >> ConstraintValidatorFactory *and* InstanceProvider. Wouldn't actually
>> >> the latter suffice? After all CVF is in it's current form only a
>> >> special kind of instance provider for validators, while
>> >> InstanceProvider implementations would create all type of BV objects,
>> >> be it validators, interpolators etc. So maybe we should deprecate CVF
>> >> when introducing InstanceProvider?
>> >
>> > Good point. Priority rules might become hairy but you are correct, we
>> should deprecate ConstraintValidatorFactory and give InstanceProvider
>> precedence in this situation.
>> >
>> >>
>> >> Regarding the name createInstance(): I'd find getInstance()
>> >> preferable. Depending on the given bean's lifecycle it might not be
>> >> newly created but an existing instance might be returned by the
>> >> instance provider.
>> >
>> > I was expecting to retrieve only dependent objects from
>> InstanceProvider:
>> >
>> > - ConstraintValidator are dependent objects (at least unless we go for
>> your alternative approach - which I'm a bit reluctant of today)
>> > - MessageREsolver and TraversableResolver can easily be dependent
>> objects and rely on injected objects from other scopes
>> >
>> > Do you see this as a problem? The alternative would be to alter the
>> contract to pass a flag when we mandate a dependent object.
>> >
>> > Thoughts?
>> >
>> >>
>> >>> 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.
>> >>
>> >> +1 For letting CDI provide a CDIInstanceProvider. The CDI spec today
>> >> already knows about BV but not the other way around, and I think we
>> >> should strive to keep it that way. There shouldn't be a circular
>> >> dependency between the specs.
>> >
>> > Gunnar that's not going to happen. Pete told me that their goal is to
>> externalize CDI integration to each spec rather than gather all logic in
>> the CDI spec. We might even have to provide the provider implementations.
>> If that's your only argument for this approach it's not strong enough.
>> >
>> >>
>> >>> 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.
>> >>
>> >> +1 for *not* injecting beans provided by the user via the bootstrap
>> >> API. If someone provides an interpolator for instance he should be
>> >> knowing what he is doing (after all the provided bean could be a CDI
>> >> bean already).
>> >
>> > Right, my line of thoughts exactly.
>> >
>> >>
>> >>> We should however let people provide `MessageInterpolator` and
>> `TraversableResolver` implementation classes.
>> >>
>> >> This would only happen via the XML configuration, right? In that case
>> >> the InstanceProvider would create the beans and perform the injection
>> >> (via CDI in case of the CDIInstanceProvider).
>> >
>> > No. I don't want to give XML a special privilege. So I am entertaining
>> the idea of have a programmatic way to pass such a class. What do you think?
>> > Arguing against myself, if someone wants to programmatically build a
>> ValidatorFactory in a DI environment, he will likely get the
>> MessageResolver and TraversalResolver from the DI by injection in his
>> provider and do the wiring there?
>> >
>> > What do you all think?
>> > _______________________________________________
>> > 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/20120105/03d7b272/attachment-0001.html 


More information about the beanvalidation-dev mailing list