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?

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&gt; 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