On Mar 21, 2007, at 7:37 PM, Prasad Kashyap wrote:
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 ?
Good question. Looking at the code, it seems like things will just
come to a halt. We may need to add something in there to fix that.
-David
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
