[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