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

[George Gastaldi]

 That´s a good question. I think that there may be more ambiguities,
but it´s something that cannot be avoided.
 I guess this is where the implementation comes in (For example, an
annotation may be created in Weld to avoid that behaviour), but then,
it may still unsolve the problem.

I wonder what the CDI spec guys has to say about it.

> 2010/4/29 Marius Bogoevici <marius.bogoevici at gmail.com>:
>> 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>
>