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

[Emmanuel Bernard]

My problem with this is that it ties two contracts together.
Say we decide that initialize() is too weak and we introduced a new richer interface for initialization, we would also need to break (again) ConstraintValidatorFactory.

It's not a strong argument but leaving initialization to the BV provider seems to limit the amount of code duplication between CVF implementors.

On 27 oct. 2011, at 00:35, Gunnar Morling wrote:

> Hi,
> 
> I thought a bit more about this and wondered whether the following might work:
> 
> * change the contract of ConstraintValidatorFactory and make it
> completely responsible for the lifecycle of validator instances:
> 
>    public interface ConstraintValidatorFactory {
> 
>        <T extends ConstraintValidator<?,?>> T getInstance(Annotation
> constraint, Class<T> key);
>    }
> 
> * By passing the constraint the factory would have all required
> information for creating and initializing validators. It could take
> care for the lifecycle and enforce the constraints required by the
> programing model (in case of CDI for instance a CDI-aware factory
> would ensure that no singleton-scoped beans are validators etc.). It
> could also cache validators per annotation (I think the same validator
> instance can safely be used for one constraint with the same values)
> and dispose validators when applicable.
> 
> * BV providers must not keep references to validators in order to not
> interfere with the lifecycle management of the factory, i.e. they must
> invoke getInstance() whenever they need a validator.
> 
> That way BV could retrieve validators created and managed by arbitrary
> CVF implementations based on their programing models such as CDI and
> BV providers wouldn't have to deal with the validator lifecycle at
> all. The default implementation would still simply instantiate (and
> initialize) validators  using the no-args constructor.
> 
> On the downside that's a breaking change, but that would be adding a
> close() hook or similar as well. And CVF implementations are typically
> only be created by BV providers or integrators but not end users.
> 
> WDYT?
> 
> --Gunnar
> 
> 
> 2011/10/25 Emmanuel Bernard <emmanuel at hibernate.org>:
>> 
>> On 24 oct. 2011, at 22:26, Gunnar Morling wrote:
>> 
>>>> 
>>>> 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.
>> 
>> yep
>> 
>>> 
>>> It would be interesting to know how CDI integration is solved for JPA
>>> entity listeners. Do you have any information on that?
>> 
>> Here is a summary though the point is still if flux at the moment:
>> 1. EntityListeners are annotated with @BeanListener (we are trying to get rid of this requirement though
>> 2. JPA providers use the CDI implementation to inject data as described in http://seamframework.org/Documentation/HowDoIDoNoncontextualInjectionForAThirdpartyFramework
>> 3. CDI's BeanManager is injected by the container during the EMF creation at a pre defined key javax.persistence.validation.factory (there is a free form Map upon EMF creation)
>> 
>> This model (esp the last point) is how BV integrates in JPA btw and it has served JPA well.
>> 
>> About point 2., Bean Validation lacks a close() hook to properly call the `dispose()` operations. We will need to add it.
>> _______________________________________________
>> 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