I'm sorry. My test class had a very dumb bug. The chain works fine.
However, can you please help me understand this better. Section 12.4 of the spec says, "Lifecycle callback interceptor methods may be defined on superclasses of the bean class or interceptor classes. However, a given class may not have more than one lifecycle callback interceptor method for the same lifecycle event." Also Section 12.4.1 says, • If a bean class has superclasses, any lifecycle callback interceptor methods defined on those superclasses are invoked, most general superclass first. • The lifecycle callback interceptor method, if any, on the bean class itself is invoked. My understanding is that for a given lifecycle event, (say PostConstruct), the bean's superclass' @PostConstruct is first called followed by the bean's @PostConstruct. Am I correct ? If correct, then how can the superclass' @PostConstruct invoke the InvocationContext.proceed() ? The method signature of a lifecycle callback method on a bean or it's superclass should be void <METHOD>() . Where can it get a handle on the InvocationContext object ? How can it proceed down the chain ? Cheers Prasad On 3/21/07, David Blevins <[EMAIL PROTECTED]> wrote:
On Mar 20, 2007, at 1:39 PM, Prasad Kashyap wrote: > https://issues.apache.org/jira/secure/attachment/12353787/ > Interceptor-v2.patch > > I have attached a patch here that defines a stateless bean and a > stateful bean with lifecycle interceptors at many levels. Both the > beans have super class with in-bean lifecycle interceptors. Then the > beans themselves have in-bean lifecycle interceptors. > > The beans declare a @Interceptor class that has lifecycle > interceptors. The interceptor has a super class with lifecycle > interceptor. > > There are printlns in the interceptor code to verify the callbacks > order. > > StatefulInterceptorTests and StatelessInterceptorTests in the client > code invoke the beans though they don't have specific test methods to > test the callbacks. See the printlns above. > > Expected results: (interceptor callback in the following order, as per > Section 12.4.1 of core spec) > ------------------------- > SuperClassInterceptor > ClassInterceptor > SuperBeanInterceptor > InBeanInterceptor > > > Actual Result: > -------------------- > SuperClassInterceptor > > > The top most interceptor in the chain executes. Then it doesn't go > down the chain. You can verify that by removing each top one and it > executes only the next one in the chain. This is strange as I seems to work in this test case: http://fisheye6.cenqua.com/browse/openejb/trunk/openejb3/container/ openejb-core/src/test/java/org/apache/openejb/core/stateless/ StatelessInterceptorTest.java?r=519214 Maybe my test case is flawed somehow. The code that should be working and perhaps does not is: 1. Get the callbacks (including @AroundInvoke) declared in the class and it's super class and add them to the descriptor tree (AnnotationDeployer:line 568)[1]. 2. Block out callbacks from parents overridden by the child. (InterceptorBindingBuilder: lines 134)[2] 3. Sort the callbacks parent first, child last (InterceptorBindingBuilder: lines 147)[3] -David [1] http://fisheye6.cenqua.com/browse/openejb/trunk/openejb3/ container/openejb-core/src/main/java/org/apache/openejb/config/ AnnotationDeployer.java?r=519454#l568 [2] http://fisheye6.cenqua.com/browse/openejb/trunk/openejb3/ container/openejb-core/src/main/java/org/apache/openejb/assembler/ classic/InterceptorBindingBuilder.java?r=519454#l134 [3] http://fisheye6.cenqua.com/browse/openejb/trunk/openejb3/ container/openejb-core/src/main/java/org/apache/openejb/assembler/ classic/InterceptorBindingBuilder.java?r=519454#l147
