2010/4/29 Marius Bogoevici <marius.bogoevici(a)gmail.com&gt;: > Hi, > > This is a question for the EG regarding a conflict that arises from the > current ability to use an EJB3-style interceptor as a managed bean. > > There seems to be a slight gap between the CDI spec and the general Java > EE notion of the interceptor, in the following respect: an EJB > interceptor (one that's not annotated with @Interceptor), may be, in > theory, used as a managed bean. Unfortunately, this leads to a conflict > with respect to the lifecycle interception methods. > > So for example we had something like: > > public class SomeClass { > >     @AroundInvoke >     public Object interceptSomething(InvocationContext context) throws > Exception { ... } > > } > > one may decide to use it either as > > @Inject SomeClass someClass; > > or @Interceptors(SomeClass.class); > > This cannot be prevented, as there is no formal way in which one can > differentiate between a managed bean with an @AroundInvoke > self-intercepting method and an EJB3-interceptor that does only business > method call interception (it is possible to do this heuristically, but > that opens the door to various interpretations).  As ambiguous as it is, > that wouldn't be so bad, until one adds a @PostConstruct method too (for > example). As this has been previously discussed here: > > http://lists.jboss.org/pipermail/weld-dev/2009-December/001913.html, > > the intent is to stay consistent with the EJB spec and not to have two > different @PostConstruct handlers for the same class.  Staying > consistent requires the lifecycle interception methods of SomeClass to > have an InvocationContext parameter (in order to be applicable on other > classes). If SomeClass was instantiated independently, as a managed > bean, its lifecycle invocation method would need to be no-arg, though. > > Now, such a dual use use-case (using a class as both an interceptor and > a managed bean) is by and large, absurd - but it is not prohibited by > the current spec. In fact, in Weld, ManagedBean and NewManagedBean > instances are created for such classes (because there is nothing to > forbid it, and in certain cases, you can't be sure whether the bean is a > managed bean or an interceptor). > > In summary: the current specification allows to use EJB3-style > interceptors as managed beans, but if they have lifecycle interception > methods, they cannot be instantiated in a way that is consistent with > the spec, because their lifecycle interceptor methods will expect an > argument that the interceptor  specification says it should not be > provided in this case. > > So, I think this needs to be somehow clarified in a future version of > the spec, either by stating explicitly that EJB3-style interceptors with > lifecycle interception methods are not managed beans, *or* at least by > saying that the use of EJB3-style interceptors as managed beans is > non-portable when they also define lifecycle methods. > > WDYT? > > Marius > _______________________________________________ > weld-dev mailing list > weld-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev >