This issue was appeared in one time. AFAK, answer was that stick with EJB interceptor specification. So if there is a @PostConstruct, it takes InvocationContext and lifecycle is managed by owner. (Not treating it as a Managed Bean) I think that spec. would clear that interceptors/decorators would not be defined as managed beans and their lifecycle methods are used by their owners not themselves. --Gurkan ________________________________ From: Marius Bogoevici <marius.bogoevici(a)gmail.com&gt; To: Weld-Dev List <weld-dev(a)lists.jboss.org>; Gavin King <gavin.king(a)gmail.com&gt; Sent: Thu, April 29, 2010 6:44:51 PM Subject: [weld-dev] Question regarding EJB3-style interceptors and their usage as managed beans 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