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
>