Menu
▾
▴
springframework-developer
|
From: Lilantha D. <Lil...@Si...> - 2005-08-29 04:35:08
|
Hi=20
=20
I'm trying a to invoke a joint point where I have two after returning
advices that I need to execute
In the order that I have specified in the config bean. My bean
definitions is something like:
=20
<bean id=3D"test"
class=3D"org.springframework.aop.framework.ProxyFactoryBean">
<property
name=3D"proxyInterfaces"><value>ITarget</value></property>
<property name=3D"target"><ref local=3D"testTarget"/></property>
<property name=3D"interceptorNames">
<value>testAdvice1,testAdvice2</value>
</property>
</bean>
<bean id=3D"testTarget" class=3D"Target"/>
=20
<bean id=3D"testAdvice1"
class=3D"org.springframework.aop.support.RegexpMethodPointcutAdvisor">
<property name=3D"advice">
<bean class=3D"AfterAdvice1"/>
</property>
<property name=3D"patterns">
<list>
<value>.*foo</value>
</list>
</property>
</bean>
<bean id=3D"testTarget" class=3D"Target"/>
=20
<bean id=3D"testAdvice2"
class=3D"org.springframework.aop.support.RegexpMethodPointcutAdvisor">
<property name=3D"advice">
<bean class=3D"AfterAdvice2"/>
</property>
<property name=3D"patterns">
<list>
<value>.*foo</value>
</list>
</property>
</bean>
=20
My expectation is, after retuning from the join point it should execute
return method of each of=20
these after advices in the same order as I have specified in the bean.
i.e. testAdvice1 followed by testAdvice2.
=20
However, it's executes them in opposite order. This seems due to
=66ollowing method of=20
AfterReturningAdviceInterceptor class.
=20
public Object invoke(MethodInvocation mi) throws Throwable {
Object retVal =3D mi.proceed();
this.advice.afterReturning(retVal, mi.getMethod(),
mi.getArguments(), mi.getThis());
return retVal;
}
=20
Appriciate if you would clarify why it is execute in opposite order=3F Is
it the intended way to execute them=3F
=20
Thanks
-Lilantha
_______________
Siebel
IT'S ALL ABOUT THE CUSTOMER
Visit www.siebel.com
This e-mail message is for the sole use of the intended recipient(s) and =
contains confidential and/or privileged information belonging to Siebel =
Systems, Inc. or its customers or partners. Any unauthorized review, use, =
copying, disclosure or distribution of this message is strictly prohibited.=
=
If you are not an intended recipient of this message, please contact the =
sender by reply e-mail and destroy all soft and hard copies of the message =
and any attachments. Thank you for your cooperation.
|
|
From: Steven D. <ste...@gm...> - 2005-08-29 08:29:36
|
Lilantha,
After returning advice is indeed processed in the opposite order.
Since the method invocation moves back up the advisor chain the last
advisor is processed first, then the second to last and so on until
all advisors have been processed.
If you would chain an number of around advices (method interceptors)
they would also be processed in the inverse order once the target
method exits although they have been called in the expected order when
the method invocation starts.
Steven
On 8/29/05, Lilantha Darshana <Lil...@si...> wrote:
> =20
> =20
>=20
> Hi=20
>=20
> =20
>=20
> I'm trying a to invoke a joint point where I have two after returning
> advices that I need to execute=20
>=20
> In the order that I have specified in the config bean. My bean definition=
s
> is something like:=20
>=20
> =20
>=20
> <bean id=3D"test"
> class=3D"org.springframework.aop.framework.ProxyFactoryBean">
>=20
> <property
> name=3D"proxyInterfaces"><value>ITarget</value></property>=20
>=20
> <property name=3D"target"><ref local=3D"testTarget"/></property=
>=20
>=20
> <property name=3D"interceptorNames">=20
>=20
> <value>testAdvice1,testAdvice2</value>=20
>=20
> </property>=20
>=20
> </bean>=20
>=20
> <bean id=3D"testTarget" class=3D"Target"/>=20
>=20
> =20
>=20
> <bean id=3D"testAdvice1"
> class=3D"org.springframework.aop.support.RegexpMethodPointcutAdvisor">
>=20
> <property name=3D"advice">=20
>=20
> <bean class=3D"AfterAdvice1"/>=20
>=20
> </property>=20
>=20
> <property name=3D"patterns">=20
>=20
> <list>=20
>=20
> <value>.*foo</value>=20
>=20
> </list>=20
>=20
> </property>=20
>=20
> </bean>=20
>=20
> <bean id=3D"testTarget" class=3D"Target"/>=20
>=20
> =20
>=20
> <bean id=3D"testAdvice2"
> class=3D"org.springframework.aop.support.RegexpMethodPointcutAdvisor">
>=20
> <property name=3D"advice">=20
>=20
> <bean class=3D"AfterAdvice2"/>=20
>=20
> </property>=20
>=20
> <property name=3D"patterns">=20
>=20
> <list>=20
>=20
> <value>.*foo</value>=20
>=20
> </list>=20
>=20
> </property>=20
>=20
> </bean>=20
>=20
> =20
>=20
> My expectation is, after retuning from the join point it should execute
> return method of each of=20
>=20
> these after advices in the same order as I have specified in the bean.=20
>=20
> i.e. testAdvice1 followed by testAdvice2.=20
>=20
> =20
>=20
> However, it's executes them in opposite order. This seems due to followin=
g
> method of=20
>=20
> AfterReturningAdviceInterceptor class.=20
>=20
> =20
>=20
> public Object invoke(MethodInvocation mi) throws Throwable {=20
>=20
> Object retVal =3D mi.proceed();=20
>=20
> this.advice.afterReturning(retVal, mi.getMethod(),
> mi.getArguments(), mi.getThis());=20
>=20
> return retVal;=20
>=20
> }=20
>=20
> =20
>=20
> Appriciate if you would clarify why it is execute in opposite order? Is i=
t
> the intended way to execute them?=20
>=20
> =20
>=20
> Thanks=20
>=20
> -Lilantha=20
>=20
> _______________
> Siebel
> IT'S ALL ABOUT THE CUSTOMER
> Visit www.siebel.com
> =20
> This e-mail message is for the sole use of the intended recipient(s) and
> contains confidential and/or privileged information belonging to Siebel
> Systems, Inc. or its customers or partners. Any unauthorized review, use,
> copying, disclosure or distribution of this message is strictly prohibite=
d.
> If you are not an intended recipient of this message, please contact the
> sender by reply e-mail and destroy all soft and hard copies of the messag=
e
> and any attachments. Thank you for your cooperation.
> =20
--=20
"If you want to be a different fish, you gotta jump out of the school."
-- Captain Beefheart
|
|
From: Alexandru P. <the...@gm...> - 2005-08-29 09:53:01
|
#: Steven Devijver changed the world a bit at a time by saying on 8/29/2005 10:29 AM :#
> Lilantha,
>
> After returning advice is indeed processed in the opposite order.
> Since the method invocation moves back up the advisor chain the last
> advisor is processed first, then the second to last and so on until
> all advisors have been processed.
>
> If you would chain an number of around advices (method interceptors)
> they would also be processed in the inverse order once the target
> method exits although they have been called in the expected order when
> the method invocation starts.
>
> Steven
>
This looks to me pretty unintuitive, because we are talking about after advices. The rules you are
exposing are correct, but they apply to around advice. I imagine that this is caused by the fact
that Spring doesn't have real before and after advices, but rather it is emulating them using always
around (this is true for all proxy based aop solutions).
:alex |.::the_mindstorm::.|
> On 8/29/05, Lilantha Darshana <Lil...@si...> wrote:
>>
>>
>>
>> Hi
>>
>>
>>
>> I'm trying a to invoke a joint point where I have two after returning
>> advices that I need to execute
>>
>> In the order that I have specified in the config bean. My bean definitions
>> is something like:
>>
>>
>>
>> <bean id="test"
>> class="org.springframework.aop.framework.ProxyFactoryBean">
>>
>> <property
>> name="proxyInterfaces"><value>ITarget</value></property>
>>
>> <property name="target"><ref local="testTarget"/></property>
>>
>> <property name="interceptorNames">
>>
>> <value>testAdvice1,testAdvice2</value>
>>
>> </property>
>>
>> </bean>
>>
>> <bean id="testTarget" class="Target"/>
>>
>>
>>
>> <bean id="testAdvice1"
>> class="org.springframework.aop.support.RegexpMethodPointcutAdvisor">
>>
>> <property name="advice">
>>
>> <bean class="AfterAdvice1"/>
>>
>> </property>
>>
>> <property name="patterns">
>>
>> <list>
>>
>> <value>.*foo</value>
>>
>> </list>
>>
>> </property>
>>
>> </bean>
>>
>> <bean id="testTarget" class="Target"/>
>>
>>
>>
>> <bean id="testAdvice2"
>> class="org.springframework.aop.support.RegexpMethodPointcutAdvisor">
>>
>> <property name="advice">
>>
>> <bean class="AfterAdvice2"/>
>>
>> </property>
>>
>> <property name="patterns">
>>
>> <list>
>>
>> <value>.*foo</value>
>>
>> </list>
>>
>> </property>
>>
>> </bean>
>>
>>
>>
>> My expectation is, after retuning from the join point it should execute
>> return method of each of
>>
>> these after advices in the same order as I have specified in the bean.
>>
>> i.e. testAdvice1 followed by testAdvice2.
>>
>>
>>
>> However, it's executes them in opposite order. This seems due to following
>> method of
>>
>> AfterReturningAdviceInterceptor class.
>>
>>
>>
>> public Object invoke(MethodInvocation mi) throws Throwable {
>>
>> Object retVal = mi.proceed();
>>
>> this.advice.afterReturning(retVal, mi.getMethod(),
>> mi.getArguments(), mi.getThis());
>>
>> return retVal;
>>
>> }
>>
>>
>>
>> Appriciate if you would clarify why it is execute in opposite order? Is it
>> the intended way to execute them?
>>
>>
>>
>> Thanks
>>
>> -Lilantha
>>
>> _______________
>> Siebel
>> IT'S ALL ABOUT THE CUSTOMER
>> Visit www.siebel.com
>>
>> This e-mail message is for the sole use of the intended recipient(s) and
>> contains confidential and/or privileged information belonging to Siebel
>> Systems, Inc. or its customers or partners. Any unauthorized review, use,
>> copying, disclosure or distribution of this message is strictly prohibited.
>> If you are not an intended recipient of this message, please contact the
>> sender by reply e-mail and destroy all soft and hard copies of the message
>> and any attachments. Thank you for your cooperation.
>>
>
>
|
|
From: Eugene K. <eu...@md...> - 2005-08-29 12:10:49
|
Alexandru Popescu wrote: >> After returning advice is indeed processed in the opposite order. >> Since the method invocation moves back up the advisor chain the last >> advisor is processed first, then the second to last and so on until >> all advisors have been processed. >> >> If you would chain an number of around advices (method interceptors) >> they would also be processed in the inverse order once the target >> method exits although they have been called in the expected order when >> the method invocation starts. > > This looks to me pretty unintuitive, because we are talking about > after advices. The rules you are exposing are correct, but they apply > to around advice. I imagine that this is caused by the fact that > Spring doesn't have real before and after advices, but rather it is > emulating them using always around (this is true for all proxy based > aop solutions). First of all there are explicit Before and After advices semantically possible with Spring. It has very little todo that actual implementation is using proxy, which is always gives an around advice. Note, that nothing actually stops user to implement Before and After interfaces in the same class and put it into the list of advices (even mixed with around advices). So, current behavior seems very logical if you'll take this fact into the account. regards, Eugene |
|
From: Alexandru P. <the...@gm...> - 2005-08-29 12:34:43
|
#: Eugene Kuleshov changed the world a bit at a time by saying on 8/29/2005 2:06 PM :# > Alexandru Popescu wrote: > >>> After returning advice is indeed processed in the opposite order. >>> Since the method invocation moves back up the advisor chain the last >>> advisor is processed first, then the second to last and so on until >>> all advisors have been processed. >>> >>> If you would chain an number of around advices (method interceptors) >>> they would also be processed in the inverse order once the target >>> method exits although they have been called in the expected order when >>> the method invocation starts. >> >> This looks to me pretty unintuitive, because we are talking about >> after advices. The rules you are exposing are correct, but they apply >> to around advice. I imagine that this is caused by the fact that >> Spring doesn't have real before and after advices, but rather it is >> emulating them using always around (this is true for all proxy based >> aop solutions). > > First of all there are explicit Before and After advices semantically > possible with Spring. It has very little todo that actual implementation > is using proxy, which is always gives an around advice. imo it doesn't matter that you are implementing Before or After as long as you refere to them as advices/interceptors and they are proxies. You will always have this ordering, because they are in fact around advices and the rules for around advices are those exposed before. this is just my opinion and I don't see any gain from continuing an argument on this matter :-). take care, :alex |.::the_mindstorm::.| > Note, that nothing actually stops user to implement Before and After > interfaces in the same class and put it into the list of advices (even > mixed with around advices). So, current behavior seems very logical if > you'll take this fact into the account. > > regards, > Eugene > |
|
From: Eugene K. <eu...@md...> - 2005-08-29 14:02:15
|
Alexandru Popescu wrote: >>> This looks to me pretty unintuitive, because we are talking about >>> after advices. The rules you are exposing are correct, but they apply >>> to around advice. I imagine that this is caused by the fact that >>> Spring doesn't have real before and after advices, but rather it is >>> emulating them using always around (this is true for all proxy based >>> aop solutions). >> >> >> First of all there are explicit Before and After advices >> semantically possible with Spring. It has very little todo that actual >> implementation is using proxy, which is always gives an around advice. > > imo it doesn't matter that you are implementing Before or After as long > as you refere to them as advices/interceptors and they are proxies. You > will always have this ordering, because they are in fact around advices > and the rules for around advices are those exposed before. > > this is just my opinion and I don't see any gain from continuing an > argument on this matter :-). Right. My point is that there is only one collection of advices in Spring bean definitions, so all advice tytes has to be somehow unified and there is nothing wrong to unify them all around advice. And if you think about it this way it is quite intuitive. :-) rergards, Eugene |
|
From: Alexandru P. <the...@gm...> - 2005-08-29 17:31:08
|
#: Eugene Kuleshov changed the world a bit at a time by saying on 8/29/2005 3:59 PM :#
> Alexandru Popescu wrote:
>
>>>> This looks to me pretty unintuitive, because we are talking about
>>>> after advices. The rules you are exposing are correct, but they apply
>>>> to around advice. I imagine that this is caused by the fact that
>>>> Spring doesn't have real before and after advices, but rather it is
>>>> emulating them using always around (this is true for all proxy based
>>>> aop solutions).
>>>
>>>
>>> First of all there are explicit Before and After advices
>>> semantically possible with Spring. It has very little todo that actual
>>> implementation is using proxy, which is always gives an around advice.
>>
>> imo it doesn't matter that you are implementing Before or After as long
>> as you refere to them as advices/interceptors and they are proxies. You
>> will always have this ordering, because they are in fact around advices
>> and the rules for around advices are those exposed before.
>>
>> this is just my opinion and I don't see any gain from continuing an
>> argument on this matter :-).
>
> Right. My point is that there is only one collection of advices in
> Spring bean definitions, so all advice tytes has to be somehow unified
> and there is nothing wrong to unify them all around advice. And if you
> think about it this way it is quite intuitive. :-)
>
>
Yep, we are both agreeing on this part :-).
:alex |.::the_mindstorm::.|
rergards,
> Eugene
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
|
