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

[Gurkan Erdogdu]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20100429/c3ed93dd/attachment-0001.html