You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Prasad Kashyap <go...@gmail.com> on 2007/05/01 17:22:03 UTC
Re: Multiple lifecycle interceptor callbacks don't work
On 3/21/07, David Blevins <da...@visi.com> wrote:
>
> On Mar 21, 2007, at 7:37 PM, Prasad Kashyap wrote:
>
> > 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.
>
Has a fix for this been added now ?
> -David
Cheers
Prasad
>
> >
> > On 3/21/07, David Blevins <da...@visi.com> 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
> >>
> >>
> >>
> >>
> >
>
>
Re: Multiple lifecycle interceptor callbacks don't work
Posted by David Blevins <da...@visi.com>.
On May 21, 2007, at 10:12 AM, Prasad Kashyap wrote:
> Opened a JIRA to track this
>
> https://issues.apache.org/jira/browse/OPENEJB-582
This one should be fixed thanks to Dain!
-David
> Cheers
> Prasad
>
> On 5/1/07, Prasad Kashyap <go...@gmail.com> wrote:
>> On 3/21/07, David Blevins <da...@visi.com> wrote:
>> >
>> > On Mar 21, 2007, at 7:37 PM, Prasad Kashyap wrote:
>> >
>> > > 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.
>> >
>>
>> Has a fix for this been added now ?
>>
>> > -David
>>
>> Cheers
>> Prasad
>>
>> >
>> > >
>> > > On 3/21/07, David Blevins <da...@visi.com> 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
>> > >>
>> > >>
>> > >>
>> > >>
>> > >
>> >
>> >
>>
>
Re: Multiple lifecycle interceptor callbacks don't work
Posted by Prasad Kashyap <go...@gmail.com>.
Opened a JIRA to track this
https://issues.apache.org/jira/browse/OPENEJB-582
Cheers
Prasad
On 5/1/07, Prasad Kashyap <go...@gmail.com> wrote:
> On 3/21/07, David Blevins <da...@visi.com> wrote:
> >
> > On Mar 21, 2007, at 7:37 PM, Prasad Kashyap wrote:
> >
> > > 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.
> >
>
> Has a fix for this been added now ?
>
> > -David
>
> Cheers
> Prasad
>
> >
> > >
> > > On 3/21/07, David Blevins <da...@visi.com> 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
> > >>
> > >>
> > >>
> > >>
> > >
> >
> >
>