springframework-developer

[Springframework-developer] Trying again. Difference in advised behavior btwn ProxyFactoryBean and TransactionProxyFactoryBean??

[Tim K. <tim...@vi...>]

I hate to come off sounding like a broken record here, but I asked about
this issue last week in the hopes that someone could elaborate further =
on
it, but didn=92t get any reply on it.  I=92m thinking maybe it got lost =
in the
events over the weekend, so I=92m re-posting both emails I sent below, =
in the
hopes that someone might afford a look at it and point me in the right
direction.  Thanks in advance!

In a nutshell, I'm seeing different behavior on how interceptors are =
applied
to an proxy object purely based on whether it is using ProxyFactoryBean =
or
TransactionProxyFactoryBean. (details are in the email below)


=3D=3D=3D=3D=3D=3D ORIGINAL EMAIL (SEE FOLLOWUP EMAIL AFTER THIS ONE) =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
I'm running into some rather unusual behavior that I cannot explain - so =
I
thought I'd bring it up here, either I'm doing something wrong, or there =
(a
far more remote possibility) is something wrong w/ Spring.

I previously had an object that was wrapped in a
TransactionProxyFactoryBean, and this object also had an Acegi security
method interceptor applied to it.=A0=20

In my refactoring of the code to move the transactional concerns to a =
higher
abstraction layer, I changed the object wrapper from
TransactionProxyFactoryBean to ProxyFactoryBean.=A0 Since I wanted to =
keep the
Acegi method interceptor at this level, I upated the 'postInterceptors'
property to 'interceptorNames', and set the name of the Acegi =
interceptor in
there.=A0=20

from this:

=A0=A0=A0 =A0=A0=A0 <property name=3D"postInterceptors">
=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 <list>
=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 <ref =
bean=3D"serviceMethodSecurityInterceptor"/>
=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 </list>
=A0=A0=A0 =A0=A0=A0 </property>

to this:

=A0=A0=A0 =A0=A0=A0 <property name=3D"interceptorNames">
=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 <list>
=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =
<value>serviceMethodSecurityInterceptor</value>
=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 </list>
=A0=A0=A0 =A0=A0=A0 </property>

Some of the test cases I have broke after this change.=A0 I started =
digging
around a bit to find out why, and what I've turned up, to the best I can
figure out is that when applying an interceptor via 'interceptorNames', =
the
interceptor gets selectively applied.=A0=A0=A0 This is the configuration =
for the
method interceptor.=A0 As you can see, we are applying access control on =
three
different methods.=A0 'get', 'getTopicList' and 'getTopicChildren'.=A0=20

=A0=A0=A0 <bean id=3D"serviceMethodSecurityInterceptor"
class=3D"net.sf.acegisecurity.intercept.method.aopalliance.MethodSecurity=
Inter
ceptor">
=A0=A0=A0 =A0=A0=A0 <property name=3D"authenticationManager"><ref
bean=3D"authenticationManager"/></property>
=A0=A0=A0=A0 =A0=A0=A0 <property name=3D"accessDecisionManager"><ref
bean=3D"decisionManager"/></property>
=A0=A0=A0 =A0=A0=A0 <property name=3D"afterInvocationManager"><ref
bean=3D"afterInvocationManager"/></property>
=A0=A0=A0 =A0=A0=A0 <property name=3D"objectDefinitionSource">
=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 <value>
=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =
com.vivakos.vps.service.Service.get=3DTOPIC_AFTER_ACL_READ
=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0
com.vivakos.vps.service.content.TopicService.getTopicList=3DTOPIC_AFTER_A=
CL_RE
AD
=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0
com.vivakos.vps.service.content.TopicService.getTopicChildren=3DTOPIC_AFT=
ER_AC
L_READ
=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 </value>
=A0=A0=A0 =A0=A0=A0 </property>
=A0=A0=A0 </bean>=A0=A0=A0 =A0=A0=A0=20

And as far as I can see - when using TransactionProxyFactoryBean, all =
three
methods get applied correctly.=A0 i.e. integration tests that test the =
'get',
'getTopicList' and 'getTopicChildren' all work properly.=A0=20

But when changing to use ProxyFactoryBean, the 'get' method integration =
test
fails (the interceptor apparently is not called), while 'getTopicList' =
and
'getTopicChildren' work integration test works fine.=A0 The only =
differnence
in how the methods that are tested is that 'get' is defined in an higher
level interface (Service) instead of (TopicService).=A0 The integration =
test
calls topicService.get() ....

I'm hoping that someone can help shine additional light on this =
difference
in behavior with the interceptors, and what I might be doing wrong?

Thanks in advance,

-tim

=3D=3D=3D=3D=3D=3D=3D=3D=3D FOLLOW UP EMAIL SENT A DAY AFTER THE =
ORIGINAL =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Following up on the previous email I sent yesterday, I explored one more
scenario.  Since the hiearchy for the 'Service' interface is like this.

Service=20
   -'.get()'

  + TopicService (extends Service)
  - .getTopicList()
  - .getTopicChildren()

And as I've mentioned in my previous email, the Acegi security method
interceptor does not seem to be kicking in on the 'get()' method when =
called
on a TopicService implementation, although it does kick in for the other =
two
methods defined under TopicService when using ProxyFactoryBean and
'interceptorNames' property. =20

So I tested out earlier today what would happen if I defined the 'get()'
method at the TopicService interface level, and updated the security =
method
interceptor from

com.vivakos.vps.service.Service.get=3DTOPIC_AFTER_ACL_READ

to=20

com.vivakos.vps.service.content.Topic.get=3DTOPIC_AFTER_ACL_READ

And the result is that it worked.  So, I'm hoping that someone with a =
better
understanding of what the differences between the ProxyFactoryBean =
advising
process and the TransactionProxyFactoryBean would be - could clarify =
what is
going on, since to me, they should work the same?

Thanks.

-tim

Re: [Springframework-developer] Trying again. Difference in advised behavior btwn ProxyFactoryBean and TransactionProxyFactoryBean??

[Steven D. <ste...@in...>]

Tim,

The only thing I can tell so far is that there shouldn't be any =20
difference in behavior between TransactionProxyFactoryBean and =20
ProxyFactoryBean. Could you please send the configuration of the =20
relevant classes before and after the changes you made?


Steven Devijver
Senior consultant
@ Interface21
ste...@in...



On 12 Sep 2005, at 23:10, Tim Kettering wrote:

>
> I hate to come off sounding like a broken record here, but I asked =20
> about
> this issue last week in the hopes that someone could elaborate =20
> further on
> it, but didn=92t get any reply on it.  I=92m thinking maybe it got =
lost =20
> in the
> events over the weekend, so I=92m re-posting both emails I sent =20
> below, in the
> hopes that someone might afford a look at it and point me in the right
> direction.  Thanks in advance!
>
> In a nutshell, I'm seeing different behavior on how interceptors =20
> are applied
> to an proxy object purely based on whether it is using =20
> ProxyFactoryBean or
> TransactionProxyFactoryBean. (details are in the email below)
>
>
> =3D=3D=3D=3D=3D=3D ORIGINAL EMAIL (SEE FOLLOWUP EMAIL AFTER THIS ONE) =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> I'm running into some rather unusual behavior that I cannot explain =20=

> - so I
> thought I'd bring it up here, either I'm doing something wrong, or =20
> there (a
> far more remote possibility) is something wrong w/ Spring.
>
> I previously had an object that was wrapped in a
> TransactionProxyFactoryBean, and this object also had an Acegi =20
> security
> method interceptor applied to it.
>
> In my refactoring of the code to move the transactional concerns to =20=

> a higher
> abstraction layer, I changed the object wrapper from
> TransactionProxyFactoryBean to ProxyFactoryBean.  Since I wanted to =20=

> keep the
> Acegi method interceptor at this level, I upated the =20
> 'postInterceptors'
> property to 'interceptorNames', and set the name of the Acegi =20
> interceptor in
> there.
>
> from this:
>
>         <property name=3D"postInterceptors">
>             <list>
>                 <ref bean=3D"serviceMethodSecurityInterceptor"/>
>             </list>
>         </property>
>
> to this:
>
>         <property name=3D"interceptorNames">
>             <list>
>                 <value>serviceMethodSecurityInterceptor</value>
>             </list>
>         </property>
>
> Some of the test cases I have broke after this change.  I started =20
> digging
> around a bit to find out why, and what I've turned up, to the best =20
> I can
> figure out is that when applying an interceptor via =20
> 'interceptorNames', the
> interceptor gets selectively applied.    This is the configuration =20
> for the
> method interceptor.  As you can see, we are applying access control =20=

> on three
> different methods.  'get', 'getTopicList' and 'getTopicChildren'.
>
>     <bean id=3D"serviceMethodSecurityInterceptor"
> class=3D"net.sf.acegisecurity.intercept.method.aopalliance.MethodSecurit=
=20
> yInter
> ceptor">
>         <property name=3D"authenticationManager"><ref
> bean=3D"authenticationManager"/></property>
>          <property name=3D"accessDecisionManager"><ref
> bean=3D"decisionManager"/></property>
>         <property name=3D"afterInvocationManager"><ref
> bean=3D"afterInvocationManager"/></property>
>         <property name=3D"objectDefinitionSource">
>             <value>
>                 =20
> com.vivakos.vps.service.Service.get=3DTOPIC_AFTER_ACL_READ
>
> com.vivakos.vps.service.content.TopicService.getTopicList=3DTOPIC_AFTER_=
=20
> ACL_RE
> AD
>
> com.vivakos.vps.service.content.TopicService.getTopicChildren=3DTOPIC_AF=
=20
> TER_AC
> L_READ
>             </value>
>         </property>
>     </bean>
>
> And as far as I can see - when using TransactionProxyFactoryBean, =20
> all three
> methods get applied correctly.  i.e. integration tests that test =20
> the 'get',
> 'getTopicList' and 'getTopicChildren' all work properly.
>
> But when changing to use ProxyFactoryBean, the 'get' method =20
> integration test
> fails (the interceptor apparently is not called), while =20
> 'getTopicList' and
> 'getTopicChildren' work integration test works fine.  The only =20
> differnence
> in how the methods that are tested is that 'get' is defined in an =20
> higher
> level interface (Service) instead of (TopicService).  The =20
> integration test
> calls topicService.get() ....
>
> I'm hoping that someone can help shine additional light on this =20
> difference
> in behavior with the interceptors, and what I might be doing wrong?
>
> Thanks in advance,
>
> -tim
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D FOLLOW UP EMAIL SENT A DAY AFTER THE =
ORIGINAL =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> Following up on the previous email I sent yesterday, I explored one =20=

> more
> scenario.  Since the hiearchy for the 'Service' interface is like =20
> this.
>
> Service
>    -'.get()'
>
>   + TopicService (extends Service)
>   - .getTopicList()
>   - .getTopicChildren()
>
> And as I've mentioned in my previous email, the Acegi security method
> interceptor does not seem to be kicking in on the 'get()' method =20
> when called
> on a TopicService implementation, although it does kick in for the =20
> other two
> methods defined under TopicService when using ProxyFactoryBean and
> 'interceptorNames' property.
>
> So I tested out earlier today what would happen if I defined the =20
> 'get()'
> method at the TopicService interface level, and updated the =20
> security method
> interceptor from
>
> com.vivakos.vps.service.Service.get=3DTOPIC_AFTER_ACL_READ
>
> to
>
> com.vivakos.vps.service.content.Topic.get=3DTOPIC_AFTER_ACL_READ
>
> And the result is that it worked.  So, I'm hoping that someone with =20=

> a better
> understanding of what the differences between the ProxyFactoryBean =20
> advising
> process and the TransactionProxyFactoryBean would be - could =20
> clarify what is
> going on, since to me, they should work the same?
>
> Thanks.
>
> -tim
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle =20
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * =20
> Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/=20
> bsce5sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>

Re: [Springframework-developer] Trying again. Difference in advised behavior btwn ProxyFactoryBean and TransactionProxyFactoryBean??

[Dmitriy K. <dko...@ru...>]

Tim,

try to add "proxyInterfaces" property to the ProxyFactoryBean =20
definition:

<property name=3D"proxyInterfaces">
     <list>
             <value>com.vivakos.vps.service.Service</value>
             <value>com.vivakos.vps.service.content.TopicService</value>
     </list>
</property>

Regards,
Dmitriy.


On Sep 12, 2005, at 5:10 PM, Tim Kettering wrote:

>
> I hate to come off sounding like a broken record here, but I asked =20
> about
> this issue last week in the hopes that someone could elaborate =20
> further on
> it, but didn=92t get any reply on it.  I=92m thinking maybe it got =
lost =20
> in the
> events over the weekend, so I=92m re-posting both emails I sent =20
> below, in the
> hopes that someone might afford a look at it and point me in the right
> direction.  Thanks in advance!
>
> In a nutshell, I'm seeing different behavior on how interceptors =20
> are applied
> to an proxy object purely based on whether it is using =20
> ProxyFactoryBean or
> TransactionProxyFactoryBean. (details are in the email below)
>
>
> =3D=3D=3D=3D=3D=3D ORIGINAL EMAIL (SEE FOLLOWUP EMAIL AFTER THIS ONE) =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> I'm running into some rather unusual behavior that I cannot explain =20=

> - so I
> thought I'd bring it up here, either I'm doing something wrong, or =20
> there (a
> far more remote possibility) is something wrong w/ Spring.
>
> I previously had an object that was wrapped in a
> TransactionProxyFactoryBean, and this object also had an Acegi =20
> security
> method interceptor applied to it.
>
> In my refactoring of the code to move the transactional concerns to =20=

> a higher
> abstraction layer, I changed the object wrapper from
> TransactionProxyFactoryBean to ProxyFactoryBean.  Since I wanted to =20=

> keep the
> Acegi method interceptor at this level, I upated the =20
> 'postInterceptors'
> property to 'interceptorNames', and set the name of the Acegi =20
> interceptor in
> there.
>
> from this:
>
>         <property name=3D"postInterceptors">
>             <list>
>                 <ref bean=3D"serviceMethodSecurityInterceptor"/>
>             </list>
>         </property>
>
> to this:
>
>         <property name=3D"interceptorNames">
>             <list>
>                 <value>serviceMethodSecurityInterceptor</value>
>             </list>
>         </property>
>
> Some of the test cases I have broke after this change.  I started =20
> digging
> around a bit to find out why, and what I've turned up, to the best =20
> I can
> figure out is that when applying an interceptor via =20
> 'interceptorNames', the
> interceptor gets selectively applied.    This is the configuration =20
> for the
> method interceptor.  As you can see, we are applying access control =20=

> on three
> different methods.  'get', 'getTopicList' and 'getTopicChildren'.
>
>     <bean id=3D"serviceMethodSecurityInterceptor"
> class=3D"net.sf.acegisecurity.intercept.method.aopalliance.MethodSecurit=
=20
> yInter
> ceptor">
>         <property name=3D"authenticationManager"><ref
> bean=3D"authenticationManager"/></property>
>          <property name=3D"accessDecisionManager"><ref
> bean=3D"decisionManager"/></property>
>         <property name=3D"afterInvocationManager"><ref
> bean=3D"afterInvocationManager"/></property>
>         <property name=3D"objectDefinitionSource">
>             <value>
>                 =20
> com.vivakos.vps.service.Service.get=3DTOPIC_AFTER_ACL_READ
>
> com.vivakos.vps.service.content.TopicService.getTopicList=3DTOPIC_AFTER_=
=20
> ACL_RE
> AD
>
> com.vivakos.vps.service.content.TopicService.getTopicChildren=3DTOPIC_AF=
=20
> TER_AC
> L_READ
>             </value>
>         </property>
>     </bean>
>
> And as far as I can see - when using TransactionProxyFactoryBean, =20
> all three
> methods get applied correctly.  i.e. integration tests that test =20
> the 'get',
> 'getTopicList' and 'getTopicChildren' all work properly.
>
> But when changing to use ProxyFactoryBean, the 'get' method =20
> integration test
> fails (the interceptor apparently is not called), while =20
> 'getTopicList' and
> 'getTopicChildren' work integration test works fine.  The only =20
> differnence
> in how the methods that are tested is that 'get' is defined in an =20
> higher
> level interface (Service) instead of (TopicService).  The =20
> integration test
> calls topicService.get() ....
>
> I'm hoping that someone can help shine additional light on this =20
> difference
> in behavior with the interceptors, and what I might be doing wrong?
>
> Thanks in advance,
>
> -tim
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D FOLLOW UP EMAIL SENT A DAY AFTER THE =
ORIGINAL =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> Following up on the previous email I sent yesterday, I explored one =20=

> more
> scenario.  Since the hiearchy for the 'Service' interface is like =20
> this.
>
> Service
>    -'.get()'
>
>   + TopicService (extends Service)
>   - .getTopicList()
>   - .getTopicChildren()
>
> And as I've mentioned in my previous email, the Acegi security method
> interceptor does not seem to be kicking in on the 'get()' method =20
> when called
> on a TopicService implementation, although it does kick in for the =20
> other two
> methods defined under TopicService when using ProxyFactoryBean and
> 'interceptorNames' property.
>
> So I tested out earlier today what would happen if I defined the =20
> 'get()'
> method at the TopicService interface level, and updated the =20
> security method
> interceptor from
>
> com.vivakos.vps.service.Service.get=3DTOPIC_AFTER_ACL_READ
>
> to
>
> com.vivakos.vps.service.content.Topic.get=3DTOPIC_AFTER_ACL_READ
>
> And the result is that it worked.  So, I'm hoping that someone with =20=

> a better
> understanding of what the differences between the ProxyFactoryBean =20
> advising
> process and the TransactionProxyFactoryBean would be - could =20
> clarify what is
> going on, since to me, they should work the same?
>
> Thanks.
>
> -tim
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle =20
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * =20
> Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/=20
> bsce5sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] Trying again. Difference in advised behavior btwn ProxyFactoryBean and TransactionProxyFactoryBean??

[Dmitriy K. <dko...@ru...>]

The difference is - if you don't specify the iterfaces to proxy, the =20
TransactionProxyFactoryBean will "auto discover" and add all the =20
interfaces implemented by the target class (if "proxyTargetClass" =20
flag is not explicitly set) and ProxyFactoryBean will use CGLIB proxy =20=

in such a scenario.

May be we should change the behavior of TransactionProxyFactoryBean =20
so it's consistent with ProxyFactoryBean in this regard? Juergen, =20
Colin, Rod, what do you think?

Dmitriy.


On Sep 12, 2005, at 8:51 PM, Dmitriy Kopylenko wrote:

> Tim,
>
> try to add "proxyInterfaces" property to the ProxyFactoryBean =20
> definition:
>
> <property name=3D"proxyInterfaces">
>     <list>
>             <value>com.vivakos.vps.service.Service</value>
>             <value>com.vivakos.vps.service.content.TopicService</=20
> value>
>     </list>
> </property>
>
> Regards,
> Dmitriy.
>
>
> On Sep 12, 2005, at 5:10 PM, Tim Kettering wrote:
>
>
>>
>> I hate to come off sounding like a broken record here, but I asked =20=

>> about
>> this issue last week in the hopes that someone could elaborate =20
>> further on
>> it, but didn=92t get any reply on it.  I=92m thinking maybe it got =20=

>> lost in the
>> events over the weekend, so I=92m re-posting both emails I sent =20
>> below, in the
>> hopes that someone might afford a look at it and point me in the =20
>> right
>> direction.  Thanks in advance!
>>
>> In a nutshell, I'm seeing different behavior on how interceptors =20
>> are applied
>> to an proxy object purely based on whether it is using =20
>> ProxyFactoryBean or
>> TransactionProxyFactoryBean. (details are in the email below)
>>
>>
>> =3D=3D=3D=3D=3D=3D ORIGINAL EMAIL (SEE FOLLOWUP EMAIL AFTER THIS ONE) =
=20
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> I'm running into some rather unusual behavior that I cannot =20
>> explain - so I
>> thought I'd bring it up here, either I'm doing something wrong, or =20=

>> there (a
>> far more remote possibility) is something wrong w/ Spring.
>>
>> I previously had an object that was wrapped in a
>> TransactionProxyFactoryBean, and this object also had an Acegi =20
>> security
>> method interceptor applied to it.
>>
>> In my refactoring of the code to move the transactional concerns =20
>> to a higher
>> abstraction layer, I changed the object wrapper from
>> TransactionProxyFactoryBean to ProxyFactoryBean.  Since I wanted =20
>> to keep the
>> Acegi method interceptor at this level, I upated the =20
>> 'postInterceptors'
>> property to 'interceptorNames', and set the name of the Acegi =20
>> interceptor in
>> there.
>>
>> from this:
>>
>>         <property name=3D"postInterceptors">
>>             <list>
>>                 <ref bean=3D"serviceMethodSecurityInterceptor"/>
>>             </list>
>>         </property>
>>
>> to this:
>>
>>         <property name=3D"interceptorNames">
>>             <list>
>>                 <value>serviceMethodSecurityInterceptor</value>
>>             </list>
>>         </property>
>>
>> Some of the test cases I have broke after this change.  I started =20
>> digging
>> around a bit to find out why, and what I've turned up, to the best =20=

>> I can
>> figure out is that when applying an interceptor via =20
>> 'interceptorNames', the
>> interceptor gets selectively applied.    This is the configuration =20=

>> for the
>> method interceptor.  As you can see, we are applying access =20
>> control on three
>> different methods.  'get', 'getTopicList' and 'getTopicChildren'.
>>
>>     <bean id=3D"serviceMethodSecurityInterceptor"
>> class=3D"net.sf.acegisecurity.intercept.method.aopalliance.MethodSecuri=
=20
>> tyInter
>> ceptor">
>>         <property name=3D"authenticationManager"><ref
>> bean=3D"authenticationManager"/></property>
>>          <property name=3D"accessDecisionManager"><ref
>> bean=3D"decisionManager"/></property>
>>         <property name=3D"afterInvocationManager"><ref
>> bean=3D"afterInvocationManager"/></property>
>>         <property name=3D"objectDefinitionSource">
>>             <value>
>>                 =20
>> com.vivakos.vps.service.Service.get=3DTOPIC_AFTER_ACL_READ
>>
>> com.vivakos.vps.service.content.TopicService.getTopicList=3DTOPIC_AFTER=
=20
>> _ACL_RE
>> AD
>>
>> com.vivakos.vps.service.content.TopicService.getTopicChildren=3DTOPIC_A=
=20
>> FTER_AC
>> L_READ
>>             </value>
>>         </property>
>>     </bean>
>>
>> And as far as I can see - when using TransactionProxyFactoryBean, =20
>> all three
>> methods get applied correctly.  i.e. integration tests that test =20
>> the 'get',
>> 'getTopicList' and 'getTopicChildren' all work properly.
>>
>> But when changing to use ProxyFactoryBean, the 'get' method =20
>> integration test
>> fails (the interceptor apparently is not called), while =20
>> 'getTopicList' and
>> 'getTopicChildren' work integration test works fine.  The only =20
>> differnence
>> in how the methods that are tested is that 'get' is defined in an =20
>> higher
>> level interface (Service) instead of (TopicService).  The =20
>> integration test
>> calls topicService.get() ....
>>
>> I'm hoping that someone can help shine additional light on this =20
>> difference
>> in behavior with the interceptors, and what I might be doing wrong?
>>
>> Thanks in advance,
>>
>> -tim
>>
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D FOLLOW UP EMAIL SENT A DAY AFTER THE =
ORIGINAL =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>
>> Following up on the previous email I sent yesterday, I explored =20
>> one more
>> scenario.  Since the hiearchy for the 'Service' interface is like =20
>> this.
>>
>> Service
>>    -'.get()'
>>
>>   + TopicService (extends Service)
>>   - .getTopicList()
>>   - .getTopicChildren()
>>
>> And as I've mentioned in my previous email, the Acegi security method
>> interceptor does not seem to be kicking in on the 'get()' method =20
>> when called
>> on a TopicService implementation, although it does kick in for the =20=

>> other two
>> methods defined under TopicService when using ProxyFactoryBean and
>> 'interceptorNames' property.
>>
>> So I tested out earlier today what would happen if I defined the =20
>> 'get()'
>> method at the TopicService interface level, and updated the =20
>> security method
>> interceptor from
>>
>> com.vivakos.vps.service.Service.get=3DTOPIC_AFTER_ACL_READ
>>
>> to
>>
>> com.vivakos.vps.service.content.Topic.get=3DTOPIC_AFTER_ACL_READ
>>
>> And the result is that it worked.  So, I'm hoping that someone =20
>> with a better
>> understanding of what the differences between the ProxyFactoryBean =20=

>> advising
>> process and the TransactionProxyFactoryBean would be - could =20
>> clarify what is
>> going on, since to me, they should work the same?
>>
>> Thanks.
>>
>> -tim
>>
>>
>>
>> -------------------------------------------------------
>> SF.Net email is Sponsored by the Better Software Conference & EXPO
>> September 19-22, 2005 * San Francisco, CA * Development Lifecycle =20
>> Practices
>> Agile & Plan-Driven Development * Managing Projects & Teams * =20
>> Testing & QA
>> Security * Process Improvement & Measurement * http://www.sqe.com/=20
>> bsce5sf
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-=20
>> developer
>>
>>
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle =20
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * =20
> Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/=20
> bsce5sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

RE: [Springframework-developer] Trying again. Difference in advised behavior btwn ProxyFactoryBean and TransactionProxyFactoryBean??

[Tim K. <tim...@gm...>]

Dmitriy,

Thanks for writing in.  The funny thing was that I actually had been using
the proxyInterfaces before, but after reviewing the javadocs, I had
determined that I didn't need to use this property because the javadocs
seemed to imply that the interfaces would be visible on their own, and that
using 'proxyInterfaces' was only necessary if you wanted to expose certain
interfaces but not others.  Am I mistaken?  

I was hoping to avoid having to use 'proxyInterfaces' because it increased
the verbosity of the xml files, since we have a fair bit of beans we are
proxying, and they all implement slightly different interfaces as well as an
common interface. 

But if indeed declaring 'proxyInterfaces' property is the "right way" to do
this, I will go and add it to all the bean definitions, but it seems
needlessly verbose to me, since TransactionProxyFactoryBean seems perfectly
capable of discovering all relevant interfaces on its own?

If I'm missing something here, please do let me know.

-tim


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Dmitriy Kopylenko
Sent: Monday, September 12, 2005 9:12 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Trying again. Difference in advised
behavior btwn ProxyFactoryBean and TransactionProxyFactoryBean??

The difference is - if you don't specify the iterfaces to proxy, the  
TransactionProxyFactoryBean will "auto discover" and add all the  
interfaces implemented by the target class (if "proxyTargetClass"  
flag is not explicitly set) and ProxyFactoryBean will use CGLIB proxy  
in such a scenario.

May be we should change the behavior of TransactionProxyFactoryBean  
so it's consistent with ProxyFactoryBean in this regard? Juergen,  
Colin, Rod, what do you think?

Dmitriy.


On Sep 12, 2005, at 8:51 PM, Dmitriy Kopylenko wrote:

> Tim,
>
> try to add "proxyInterfaces" property to the ProxyFactoryBean  
> definition:
>
> <property name="proxyInterfaces">
>     <list>
>             <value>com.vivakos.vps.service.Service</value>
>             <value>com.vivakos.vps.service.content.TopicService</ 
> value>
>     </list>
> </property>
>
> Regards,
> Dmitriy.
>
>
> On Sep 12, 2005, at 5:10 PM, Tim Kettering wrote:
>
>
>>
>> I hate to come off sounding like a broken record here, but I asked  
>> about
>> this issue last week in the hopes that someone could elaborate  
>> further on
>> it, but didn't get any reply on it.  I'm thinking maybe it got  
>> lost in the
>> events over the weekend, so I'm re-posting both emails I sent  
>> below, in the
>> hopes that someone might afford a look at it and point me in the  
>> right
>> direction.  Thanks in advance!
>>
>> In a nutshell, I'm seeing different behavior on how interceptors  
>> are applied
>> to an proxy object purely based on whether it is using  
>> ProxyFactoryBean or
>> TransactionProxyFactoryBean. (details are in the email below)
>>
>>
>> ====== ORIGINAL EMAIL (SEE FOLLOWUP EMAIL AFTER THIS ONE)  
>> ============
>> I'm running into some rather unusual behavior that I cannot  
>> explain - so I
>> thought I'd bring it up here, either I'm doing something wrong, or  
>> there (a
>> far more remote possibility) is something wrong w/ Spring.
>>
>> I previously had an object that was wrapped in a
>> TransactionProxyFactoryBean, and this object also had an Acegi  
>> security
>> method interceptor applied to it.
>>
>> In my refactoring of the code to move the transactional concerns  
>> to a higher
>> abstraction layer, I changed the object wrapper from
>> TransactionProxyFactoryBean to ProxyFactoryBean.  Since I wanted  
>> to keep the
>> Acegi method interceptor at this level, I upated the  
>> 'postInterceptors'
>> property to 'interceptorNames', and set the name of the Acegi  
>> interceptor in
>> there.
>>
>> from this:
>>
>>         <property name="postInterceptors">
>>             <list>
>>                 <ref bean="serviceMethodSecurityInterceptor"/>
>>             </list>
>>         </property>
>>
>> to this:
>>
>>         <property name="interceptorNames">
>>             <list>
>>                 <value>serviceMethodSecurityInterceptor</value>
>>             </list>
>>         </property>
>>
>> Some of the test cases I have broke after this change.  I started  
>> digging
>> around a bit to find out why, and what I've turned up, to the best  
>> I can
>> figure out is that when applying an interceptor via  
>> 'interceptorNames', the
>> interceptor gets selectively applied.    This is the configuration  
>> for the
>> method interceptor.  As you can see, we are applying access  
>> control on three
>> different methods.  'get', 'getTopicList' and 'getTopicChildren'.
>>
>>     <bean id="serviceMethodSecurityInterceptor"
>> class="net.sf.acegisecurity.intercept.method.aopalliance.MethodSecuri 
>> tyInter
>> ceptor">
>>         <property name="authenticationManager"><ref
>> bean="authenticationManager"/></property>
>>          <property name="accessDecisionManager"><ref
>> bean="decisionManager"/></property>
>>         <property name="afterInvocationManager"><ref
>> bean="afterInvocationManager"/></property>
>>         <property name="objectDefinitionSource">
>>             <value>
>>                  
>> com.vivakos.vps.service.Service.get=TOPIC_AFTER_ACL_READ
>>
>> com.vivakos.vps.service.content.TopicService.getTopicList=TOPIC_AFTER 
>> _ACL_RE
>> AD
>>
>> com.vivakos.vps.service.content.TopicService.getTopicChildren=TOPIC_A 
>> FTER_AC
>> L_READ
>>             </value>
>>         </property>
>>     </bean>
>>
>> And as far as I can see - when using TransactionProxyFactoryBean,  
>> all three
>> methods get applied correctly.  i.e. integration tests that test  
>> the 'get',
>> 'getTopicList' and 'getTopicChildren' all work properly.
>>
>> But when changing to use ProxyFactoryBean, the 'get' method  
>> integration test
>> fails (the interceptor apparently is not called), while  
>> 'getTopicList' and
>> 'getTopicChildren' work integration test works fine.  The only  
>> differnence
>> in how the methods that are tested is that 'get' is defined in an  
>> higher
>> level interface (Service) instead of (TopicService).  The  
>> integration test
>> calls topicService.get() ....
>>
>> I'm hoping that someone can help shine additional light on this  
>> difference
>> in behavior with the interceptors, and what I might be doing wrong?
>>
>> Thanks in advance,
>>
>> -tim
>>
>> ========= FOLLOW UP EMAIL SENT A DAY AFTER THE ORIGINAL ==========
>>
>> Following up on the previous email I sent yesterday, I explored  
>> one more
>> scenario.  Since the hiearchy for the 'Service' interface is like  
>> this.
>>
>> Service
>>    -'.get()'
>>
>>   + TopicService (extends Service)
>>   - .getTopicList()
>>   - .getTopicChildren()
>>
>> And as I've mentioned in my previous email, the Acegi security method
>> interceptor does not seem to be kicking in on the 'get()' method  
>> when called
>> on a TopicService implementation, although it does kick in for the  
>> other two
>> methods defined under TopicService when using ProxyFactoryBean and
>> 'interceptorNames' property.
>>
>> So I tested out earlier today what would happen if I defined the  
>> 'get()'
>> method at the TopicService interface level, and updated the  
>> security method
>> interceptor from
>>
>> com.vivakos.vps.service.Service.get=TOPIC_AFTER_ACL_READ
>>
>> to
>>
>> com.vivakos.vps.service.content.Topic.get=TOPIC_AFTER_ACL_READ
>>
>> And the result is that it worked.  So, I'm hoping that someone  
>> with a better
>> understanding of what the differences between the ProxyFactoryBean  
>> advising
>> process and the TransactionProxyFactoryBean would be - could  
>> clarify what is
>> going on, since to me, they should work the same?
>>
>> Thanks.
>>
>> -tim
>>
>>
>>
>> -------------------------------------------------------
>> 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
>>
>>
>
>
>
> -------------------------------------------------------
> 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
>



-------------------------------------------------------
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

Re: [Springframework-developer] Trying again. Difference in advised behavior btwn ProxyFactoryBean and TransactionProxyFactoryBean??

[Colin S. <col...@ex...>]

Personally, I think that makes some sense, but it's quite probably too 
risky to the extent of breaking backwards compatibility. you would have 
some code that is now proxied with ProxyFactoryBean that depends on 
having the class proxied as well (via the cglib proxy) that would no 
longer have the class proxied (if that class implements any interfaces).

But it's a bummer that the behavior is different. This probably deserves 
a JavaDoc comment at the minimum.

The other thing that has also always bothered me about the difference 
between ProxyFactoryBeand and TransactionProxyFactoryBean is that only 
the former can handle prototypes. There's no good reason for that; you 
do need to wrap prototypes transactionally too.

Dmitriy Kopylenko wrote:

> The difference is - if you don't specify the iterfaces to proxy, the  
> TransactionProxyFactoryBean will "auto discover" and add all the  
> interfaces implemented by the target class (if "proxyTargetClass"  
> flag is not explicitly set) and ProxyFactoryBean will use CGLIB proxy  
> in such a scenario.
>
> May be we should change the behavior of TransactionProxyFactoryBean  
> so it's consistent with ProxyFactoryBean in this regard? Juergen,  
> Colin, Rod, what do you think?
>
> Dmitriy.
>
>
> On Sep 12, 2005, at 8:51 PM, Dmitriy Kopylenko wrote:
>
>> Tim,
>>
>> try to add "proxyInterfaces" property to the ProxyFactoryBean  
>> definition:
>>
>> <property name="proxyInterfaces">
>>     <list>
>>             <value>com.vivakos.vps.service.Service</value>
>>             <value>com.vivakos.vps.service.content.TopicService</ value>
>>     </list>
>> </property>
>>
>> Regards,
>> Dmitriy.
>>
>>
>> On Sep 12, 2005, at 5:10 PM, Tim Kettering wrote:
>>
>>
>>>
>>> I hate to come off sounding like a broken record here, but I asked  
>>> about
>>> this issue last week in the hopes that someone could elaborate  
>>> further on
>>> it, but didn’t get any reply on it.  I’m thinking maybe it got  lost 
>>> in the
>>> events over the weekend, so I’m re-posting both emails I sent  
>>> below, in the
>>> hopes that someone might afford a look at it and point me in the  right
>>> direction.  Thanks in advance!
>>>
>>> In a nutshell, I'm seeing different behavior on how interceptors  
>>> are applied
>>> to an proxy object purely based on whether it is using  
>>> ProxyFactoryBean or
>>> TransactionProxyFactoryBean. (details are in the email below)
>>>
>>>
>>> ====== ORIGINAL EMAIL (SEE FOLLOWUP EMAIL AFTER THIS ONE)  ============
>>> I'm running into some rather unusual behavior that I cannot  explain 
>>> - so I
>>> thought I'd bring it up here, either I'm doing something wrong, or  
>>> there (a
>>> far more remote possibility) is something wrong w/ Spring.
>>>
>>> I previously had an object that was wrapped in a
>>> TransactionProxyFactoryBean, and this object also had an Acegi  
>>> security
>>> method interceptor applied to it.
>>>
>>> In my refactoring of the code to move the transactional concerns  to 
>>> a higher
>>> abstraction layer, I changed the object wrapper from
>>> TransactionProxyFactoryBean to ProxyFactoryBean.  Since I wanted  to 
>>> keep the
>>> Acegi method interceptor at this level, I upated the  
>>> 'postInterceptors'
>>> property to 'interceptorNames', and set the name of the Acegi  
>>> interceptor in
>>> there.
>>>
>>> from this:
>>>
>>>         <property name="postInterceptors">
>>>             <list>
>>>                 <ref bean="serviceMethodSecurityInterceptor"/>
>>>             </list>
>>>         </property>
>>>
>>> to this:
>>>
>>>         <property name="interceptorNames">
>>>             <list>
>>>                 <value>serviceMethodSecurityInterceptor</value>
>>>             </list>
>>>         </property>
>>>
>>> Some of the test cases I have broke after this change.  I started  
>>> digging
>>> around a bit to find out why, and what I've turned up, to the best  
>>> I can
>>> figure out is that when applying an interceptor via  
>>> 'interceptorNames', the
>>> interceptor gets selectively applied.    This is the configuration  
>>> for the
>>> method interceptor.  As you can see, we are applying access  control 
>>> on three
>>> different methods.  'get', 'getTopicList' and 'getTopicChildren'.
>>>
>>>     <bean id="serviceMethodSecurityInterceptor"
>>> class="net.sf.acegisecurity.intercept.method.aopalliance.MethodSecuri 
>>> tyInter
>>> ceptor">
>>>         <property name="authenticationManager"><ref
>>> bean="authenticationManager"/></property>
>>>          <property name="accessDecisionManager"><ref
>>> bean="decisionManager"/></property>
>>>         <property name="afterInvocationManager"><ref
>>> bean="afterInvocationManager"/></property>
>>>         <property name="objectDefinitionSource">
>>>             <value>
>>>                  
>>> com.vivakos.vps.service.Service.get=TOPIC_AFTER_ACL_READ
>>>
>>> com.vivakos.vps.service.content.TopicService.getTopicList=TOPIC_AFTER 
>>> _ACL_RE
>>> AD
>>>
>>> com.vivakos.vps.service.content.TopicService.getTopicChildren=TOPIC_A 
>>> FTER_AC
>>> L_READ
>>>             </value>
>>>         </property>
>>>     </bean>
>>>
>>> And as far as I can see - when using TransactionProxyFactoryBean,  
>>> all three
>>> methods get applied correctly.  i.e. integration tests that test  
>>> the 'get',
>>> 'getTopicList' and 'getTopicChildren' all work properly.
>>>
>>> But when changing to use ProxyFactoryBean, the 'get' method  
>>> integration test
>>> fails (the interceptor apparently is not called), while  
>>> 'getTopicList' and
>>> 'getTopicChildren' work integration test works fine.  The only  
>>> differnence
>>> in how the methods that are tested is that 'get' is defined in an  
>>> higher
>>> level interface (Service) instead of (TopicService).  The  
>>> integration test
>>> calls topicService.get() ....
>>>
>>> I'm hoping that someone can help shine additional light on this  
>>> difference
>>> in behavior with the interceptors, and what I might be doing wrong?
>>>
>>> Thanks in advance,
>>>
>>> -tim
>>>
>>> ========= FOLLOW UP EMAIL SENT A DAY AFTER THE ORIGINAL ==========
>>>
>>> Following up on the previous email I sent yesterday, I explored  one 
>>> more
>>> scenario.  Since the hiearchy for the 'Service' interface is like  
>>> this.
>>>
>>> Service
>>>    -'.get()'
>>>
>>>   + TopicService (extends Service)
>>>   - .getTopicList()
>>>   - .getTopicChildren()
>>>
>>> And as I've mentioned in my previous email, the Acegi security method
>>> interceptor does not seem to be kicking in on the 'get()' method  
>>> when called
>>> on a TopicService implementation, although it does kick in for the  
>>> other two
>>> methods defined under TopicService when using ProxyFactoryBean and
>>> 'interceptorNames' property.
>>>
>>> So I tested out earlier today what would happen if I defined the  
>>> 'get()'
>>> method at the TopicService interface level, and updated the  
>>> security method
>>> interceptor from
>>>
>>> com.vivakos.vps.service.Service.get=TOPIC_AFTER_ACL_READ
>>>
>>> to
>>>
>>> com.vivakos.vps.service.content.Topic.get=TOPIC_AFTER_ACL_READ
>>>
>>> And the result is that it worked.  So, I'm hoping that someone  with 
>>> a better
>>> understanding of what the differences between the ProxyFactoryBean  
>>> advising
>>> process and the TransactionProxyFactoryBean would be - could  
>>> clarify what is
>>> going on, since to me, they should work the same?
>>>
>>> Thanks.
>>>
>>> -tim
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> 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
>>>
>>>
>>
>>
>>
>> -------------------------------------------------------
>> 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
>>
>
>
>
> -------------------------------------------------------
> 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

Re: [Springframework-developer] Trying again. Difference in advised behavior btwn ProxyFactoryBean and TransactionProxyFactoryBean??

[Tim K. <tim...@gm...>]

Colin,=20

Thanks for clarifying this. I'm wondering then what would be my best option=
=20
here then. I have a fair bit of beans that are declared in the config, and=
=20
they all implement some common interfaces, and some slightly different ones=
,=20
so my head already hurts from thinking I need to go through all of them and=
=20
apply the right interfaces, and not to mention making sure they stay in syn=
c=20
with any new changes.

Some ideas I thought - creating my own "fixed" version of ProxyFactoryBean=
=20
that works similiarly to the TransactionProxyFactory behavior. Or this coul=
d=20
be introduced in the spring codebase as an alternative.=20

Or introduce the fixed strategy (along with wrapping prototypes) into=20
ProxyFactoryBean, and make it configurable via an property? So that the=20
default would be the classic approach, and for those who need the newer=20
approach, it could be set.=20

Just throwin out ideas here. I'd like this to be resolved on the spring=20
codebase side - than me plowing through all my configs, and adding=20
interfaces, only as a last resort, if a fix is untenable.

Thanks!

-tim

On 9/13/05, Colin Sampaleanu <col...@ex...> wrote:
>=20
> Personally, I think that makes some sense, but it's quite probably too
> risky to the extent of breaking backwards compatibility. you would have
> some code that is now proxied with ProxyFactoryBean that depends on
> having the class proxied as well (via the cglib proxy) that would no
> longer have the class proxied (if that class implements any interfaces).
>=20
> But it's a bummer that the behavior is different. This probably deserves
> a JavaDoc comment at the minimum.
>=20
> The other thing that has also always bothered me about the difference
> between ProxyFactoryBeand and TransactionProxyFactoryBean is that only
> the former can handle prototypes. There's no good reason for that; you
> do need to wrap prototypes transactionally too.
>=20
> Dmitriy Kopylenko wrote:
>=20
> > The difference is - if you don't specify the iterfaces to proxy, the
> > TransactionProxyFactoryBean will "auto discover" and add all the
> > interfaces implemented by the target class (if "proxyTargetClass"
> > flag is not explicitly set) and ProxyFactoryBean will use CGLIB proxy
> > in such a scenario.
> >
> > May be we should change the behavior of TransactionProxyFactoryBean
> > so it's consistent with ProxyFactoryBean in this regard? Juergen,
> > Colin, Rod, what do you think?
> >
> > Dmitriy.
> >
> >
> > On Sep 12, 2005, at 8:51 PM, Dmitriy Kopylenko wrote:
> >
> >> Tim,
> >>
> >> try to add "proxyInterfaces" property to the ProxyFactoryBean
> >> definition:
> >>
> >> <property name=3D"proxyInterfaces">
> >> <list>
> >> <value>com.vivakos.vps.service.Service</value>
> >> <value>com.vivakos.vps.service.content.TopicService</ value>
> >> </list>
> >> </property>
> >>
> >> Regards,
> >> Dmitriy.
> >>
> >>
> >> On Sep 12, 2005, at 5:10 PM, Tim Kettering wrote:
> >>
> >>
> >>>
> >>> I hate to come off sounding like a broken record here, but I asked
> >>> about
> >>> this issue last week in the hopes that someone could elaborate
> >>> further on
> >>> it, but didn't get any reply on it. I'm thinking maybe it got lost
> >>> in the
> >>> events over the weekend, so I'm re-posting both emails I sent
> >>> below, in the
> >>> hopes that someone might afford a look at it and point me in the righ=
t
> >>> direction. Thanks in advance!
> >>>
> >>> In a nutshell, I'm seeing different behavior on how interceptors
> >>> are applied
> >>> to an proxy object purely based on whether it is using
> >>> ProxyFactoryBean or
> >>> TransactionProxyFactoryBean. (details are in the email below)
> >>>
> >>>
> >>> =3D=3D=3D=3D=3D=3D ORIGINAL EMAIL (SEE FOLLOWUP EMAIL AFTER THIS ONE)=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >>> I'm running into some rather unusual behavior that I cannot explain
> >>> - so I
> >>> thought I'd bring it up here, either I'm doing something wrong, or
> >>> there (a
> >>> far more remote possibility) is something wrong w/ Spring.
> >>>
> >>> I previously had an object that was wrapped in a
> >>> TransactionProxyFactoryBean, and this object also had an Acegi
> >>> security
> >>> method interceptor applied to it.
> >>>
> >>> In my refactoring of the code to move the transactional concerns to
> >>> a higher
> >>> abstraction layer, I changed the object wrapper from
> >>> TransactionProxyFactoryBean to ProxyFactoryBean. Since I wanted to
> >>> keep the
> >>> Acegi method interceptor at this level, I upated the
> >>> 'postInterceptors'
> >>> property to 'interceptorNames', and set the name of the Acegi
> >>> interceptor in
> >>> there.
> >>>
> >>> from this:
> >>>
> >>> <property name=3D"postInterceptors">
> >>> <list>
> >>> <ref bean=3D"serviceMethodSecurityInterceptor"/>
> >>> </list>
> >>> </property>
> >>>
> >>> to this:
> >>>
> >>> <property name=3D"interceptorNames">
> >>> <list>
> >>> <value>serviceMethodSecurityInterceptor</value>
> >>> </list>
> >>> </property>
> >>>
> >>> Some of the test cases I have broke after this change. I started
> >>> digging
> >>> around a bit to find out why, and what I've turned up, to the best
> >>> I can
> >>> figure out is that when applying an interceptor via
> >>> 'interceptorNames', the
> >>> interceptor gets selectively applied. This is the configuration
> >>> for the
> >>> method interceptor. As you can see, we are applying access control
> >>> on three
> >>> different methods. 'get', 'getTopicList' and 'getTopicChildren'.
> >>>
> >>> <bean id=3D"serviceMethodSecurityInterceptor"
> >>> class=3D"net.sf.acegisecurity.intercept.method.aopalliance.MethodSecu=
ri
> >>> tyInter
> >>> ceptor">
> >>> <property name=3D"authenticationManager"><ref
> >>> bean=3D"authenticationManager"/></property>
> >>> <property name=3D"accessDecisionManager"><ref
> >>> bean=3D"decisionManager"/></property>
> >>> <property name=3D"afterInvocationManager"><ref
> >>> bean=3D"afterInvocationManager"/></property>
> >>> <property name=3D"objectDefinitionSource">
> >>> <value>
> >>>
> >>> com.vivakos.vps.service.Service.get=3DTOPIC_AFTER_ACL_READ
> >>>
> >>> com.vivakos.vps.service.content.TopicService.getTopicList=3DTOPIC_AFT=
ER
> >>> _ACL_RE
> >>> AD
> >>>
> >>> com.vivakos.vps.service.content.TopicService.getTopicChildren=3DTOPIC=
_A
> >>> FTER_AC
> >>> L_READ
> >>> </value>
> >>> </property>
> >>> </bean>
> >>>
> >>> And as far as I can see - when using TransactionProxyFactoryBean,
> >>> all three
> >>> methods get applied correctly. i.e. integration tests that test
> >>> the 'get',
> >>> 'getTopicList' and 'getTopicChildren' all work properly.
> >>>
> >>> But when changing to use ProxyFactoryBean, the 'get' method
> >>> integration test
> >>> fails (the interceptor apparently is not called), while
> >>> 'getTopicList' and
> >>> 'getTopicChildren' work integration test works fine. The only
> >>> differnence
> >>> in how the methods that are tested is that 'get' is defined in an
> >>> higher
> >>> level interface (Service) instead of (TopicService). The
> >>> integration test
> >>> calls topicService.get() ....
> >>>
> >>> I'm hoping that someone can help shine additional light on this
> >>> difference
> >>> in behavior with the interceptors, and what I might be doing wrong?
> >>>
> >>> Thanks in advance,
> >>>
> >>> -tim
> >>>
> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D FOLLOW UP EMAIL SENT A DAY AFTER THE ORIG=
INAL =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >>>
> >>> Following up on the previous email I sent yesterday, I explored one
> >>> more
> >>> scenario. Since the hiearchy for the 'Service' interface is like
> >>> this.
> >>>
> >>> Service
> >>> -'.get()'
> >>>
> >>> + TopicService (extends Service)
> >>> - .getTopicList()
> >>> - .getTopicChildren()
> >>>
> >>> And as I've mentioned in my previous email, the Acegi security method
> >>> interceptor does not seem to be kicking in on the 'get()' method
> >>> when called
> >>> on a TopicService implementation, although it does kick in for the
> >>> other two
> >>> methods defined under TopicService when using ProxyFactoryBean and
> >>> 'interceptorNames' property.
> >>>
> >>> So I tested out earlier today what would happen if I defined the
> >>> 'get()'
> >>> method at the TopicService interface level, and updated the
> >>> security method
> >>> interceptor from
> >>>
> >>> com.vivakos.vps.service.Service.get=3DTOPIC_AFTER_ACL_READ
> >>>
> >>> to
> >>>
> >>> com.vivakos.vps.service.content.Topic.get=3DTOPIC_AFTER_ACL_READ
> >>>
> >>> And the result is that it worked. So, I'm hoping that someone with
> >>> a better
> >>> understanding of what the differences between the ProxyFactoryBean
> >>> advising
> >>> process and the TransactionProxyFactoryBean would be - could
> >>> clarify what is
> >>> going on, since to me, they should work the same?
> >>>
> >>> Thanks.
> >>>
> >>> -tim
> >>>
> >>>
> >>>
> >>> -------------------------------------------------------
> >>> 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-develope=
r
> >>>
> >>>
> >>
> >>
> >>
> >> -------------------------------------------------------
> >> 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
> >>
> >
> >
> >
> > -------------------------------------------------------
> > 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 *=20
> http://www.sqe.com/bsce5sf
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server.=20
> Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

[Springframework-developer] OT: spam with raw language in spanish in Springframework home page

[Gustavo F. <gfa...@gm...>]

Do not know the appropiate channel but just in case,
There is a posting in spanish in the
www.springframework.org<http://www.springframework.org>home page that
is actually full of #$%&* in spanish. Subject for that
posting says : Desprecio Spring.

It better must be removed from there.

Gustavo.

[Springframework-developer] Re: OT: spam with raw language in spanish in Springframework home page

[Gustavo F. <gfa...@gm...>]

The offending posting is in the support page, sorry about the wrong pointer=
.

On 9/14/05, Gustavo Faerman <gfa...@gm...> wrote:
>=20
> Do not know the appropiate channel but just in case,
> There is a posting in spanish in the www.springframework.org<http://www.s=
pringframework.org>home page that is actually full of #$%&* in spanish. Sub=
ject for that=20
> posting says : Desprecio Spring.
>=20
> It better must be removed from there.
>=20
> Gustavo.
>=20
>=20
>

Re: [Springframework-developer] OT: spam with raw language in spanish in Springframework home page

[Dmitriy K. <dko...@ru...>]

Removed. Just curious - what did it say?

Dmitriy.


On Sep 14, 2005, at 1:46 PM, Gustavo Faerman wrote:

> Do not know the appropiate channel but just in case,
> There is a posting in spanish in the www.springframework.org home  
> page that is actually full of #$%&* in spanish. Subject for that  
> posting says : Desprecio Spring.
>
> It better must be removed from there.
>
> Gustavo.
>
>