---

From: Marius Bogoevici <marius.bogoevici@gmail.com>
To: Weld-Dev List <weld-dev@lists.jboss.org>; Gavin King <gavin.king@gmail.com>
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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev