[weld-dev] Question regarding EJB3-style interceptors and their usage as managed beans

Marius Bogoevici marius.bogoevici at gmail.com
Thu Apr 29 11:44:51 EDT 2010


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 {

     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:


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.



More information about the weld-dev mailing list