5:35 p.m.
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(a)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/HowDoIDoNoncontextualInjectionForA...
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev