7:13 a.m.
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(a)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(a)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(a)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(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