method-validation should be easy
(you just have to change the ProcessAnnotatedType during bootstrapping (of
the cdi container) via a portable cdi extension
-> there is no need for a bv-implementation to cache/... something here).
constructor-validation (esp. handling detected violations) is the difficult
part.
regards,
gerhard
2013/2/7 Michael Nascimento <misterm(a)gmail.com>
Binding the inceptor to the annotation is simply a matter of
enhancing
its metadata via an extension. Supporting the information declared via
xml is also possible via a CDI extension. Both solutions will be
executed while the CDI container is booting, so there is no need for
caching.
If we had a dynamic API, that allowed this to be changed during
runtime, then you would need something different.
Regards,
Michael
On Mon, Feb 4, 2013 at 4:08 PM, Emmanuel Bernard <emmanuel(a)hibernate.org>
wrote:
> While reviewing the interceptor specification, I realized that
> interceptors lifecycle is bound to the object lifecycle they intercept.
> In other words, it is not trivial to keep caches around for example
> caches that now if a method should be intercepted or not.
>
> Is that a problem for the expected CDI interceptor implementations?
> I am asking to make sure we are not making a mistake by not considering
> @ValidateExecutable in BV engines.
>
> An interceptor should either:
>
> - explicitly be set only on the methods that should be intercepted and
> not more
> - always recompute @ValidatedExecutable for every new instance of the
> targeted object
> - use some third party CDI bean responsible for the caching
>
> In other words are we good?
> _______________________________________________
> 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