<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:arial,helvetica,sans-serif;font-size:10pt">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)<br><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt;"><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt;"><br> 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.<br><br>--Gurkan<br><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt;"><br><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt;"><font face="Tahoma"
size="2"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> Marius Bogoevici <marius.bogoevici@gmail.com><br><b><span style="font-weight: bold;">To:</span></b> Weld-Dev List
<weld-dev@lists.jboss.org>; Gavin King <gavin.king@gmail.com><br><b><span style="font-weight: bold;">Sent:</span></b> Thu, April 29, 2010 6:44:51 PM<br><b><span style="font-weight: bold;">Subject:</span></b> [weld-dev] Question regarding EJB3-style interceptors and their usage as managed beans<br></font><br>Hi,<br><br>This is a question for the EG regarding a conflict that arises from the <br>current ability to use an EJB3-style interceptor as a managed bean.<br><br>There seems to be a slight gap between the CDI spec and the general Java <br>EE notion of the interceptor, in the following respect: an EJB <br>interceptor (one that's not annotated with @Interceptor), may be, in <br>theory, used as a managed bean. Unfortunately, this leads to a conflict <br>with respect to the lifecycle interception methods.<br><br>So for example we had something like:<br><br>public class SomeClass {<br><br> @AroundInvoke<br> public
Object interceptSomething(InvocationContext context) throws <br>Exception { ... }<br><br>}<br><br>one may decide to use it either as<br><br>@Inject SomeClass someClass;<br><br>or @Interceptors(SomeClass.class);<br><br>This cannot be prevented, as there is no formal way in which one can <br>differentiate between a managed bean with an @AroundInvoke <br>self-intercepting method and an EJB3-interceptor that does only business <br>method call interception (it is possible to do this heuristically, but <br>that opens the door to various interpretations). As ambiguous as it is, <br>that wouldn't be so bad, until one adds a @PostConstruct method too (for <br>example). As this has been previously discussed here:<br><br><a rel="nofollow" target="_blank" href="http://lists.jboss.org/pipermail/weld-dev/2009-December/001913.html">http://lists.jboss.org/pipermail/weld-dev/2009-December/001913.html</a>,<br><br>the intent is to stay consistent with the EJB spec
and not to have
two <br>different @PostConstruct handlers for the same class. Staying <br>consistent requires the lifecycle interception methods of SomeClass to <br>have an InvocationContext parameter (in order to be applicable on other <br>classes). If SomeClass was instantiated independently, as a managed <br>bean, its lifecycle invocation method would need to be no-arg, though.<br><br>Now, such a dual use use-case (using a class as both an interceptor and <br>a managed bean) is by and large, absurd - but it is not prohibited by <br>the current spec. In fact, in Weld, ManagedBean and NewManagedBean <br>instances are created for such classes (because there is nothing to <br>forbid it, and in certain cases, you can't be sure whether the bean is a <br>managed bean or an interceptor).<br><br>In summary: the current specification allows to use EJB3-style <br>interceptors as managed beans, but if they have lifecycle interception <br>methods, they cannot be
instantiated in a way that is consistent with <br>the spec, because their lifecycle interceptor methods will expect an <br>argument that the interceptor specification says it should not be <br>provided in this case.<br><br>So, I think this needs to be somehow clarified in a future version of <br>the spec, either by stating explicitly that EJB3-style interceptors with <br>lifecycle interception methods are not managed beans, *or* at least by <br>saying that the use of EJB3-style interceptors as managed beans is <br>non-portable when they also define lifecycle methods.<br><br>WDYT?<br><br>Marius<br>_______________________________________________<br>weld-dev mailing list<br><a rel="nofollow" ymailto="mailto:weld-dev@lists.jboss.org" target="_blank" href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a><br><a rel="nofollow" target="_blank"
href="https://lists.jboss.org/mailman/listinfo/weld-dev">https://lists.jboss.org/mailman/listinfo/weld-dev</a><br></div></div>
</div><br><meta http-equiv="x-dns-prefetch-control" content="on"></div></div>
</div><br></body></html>