|
From: Tim K. <tim...@gm...> - 2005-09-09 00:49:40
|
I'm running into some rather unusual behavior that I cannot explain - so I= =20 thought I'd bring it up here, either I'm doing something wrong, or there (a= =20 far more remote possibility) is something wrong w/ Spring. I previously had an object that was wrapped in a=20 TransactionProxyFactoryBean, and this object also had an Acegi security=20 method interceptor applied to it.=20 In my refactoring of the code to move the transactional concerns to a highe= r=20 abstraction layer, I changed the object wrapper from=20 TransactionProxyFactoryBean to ProxyFactoryBean. Since I wanted to keep the= =20 Acegi method interceptor at this level, I upated the 'postInterceptors'=20 property to 'interceptorNames', and set the name of the Acegi interceptor i= n=20 there.=20 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=20 around a bit to find out why, and what I've turned up, to the best I can=20 figure out is that when applying an interceptor via 'interceptorNames', the= =20 interceptor gets selectively applied. This is the configuration for the=20 method interceptor. As you can see, we are applying access control on three= =20 different methods. 'get', 'getTopicList' and 'getTopicChildren'.=20 <bean id=3D"serviceMethodSecurityInterceptor" class=3D" net.sf.acegisecurity.intercept.method.aopalliance.MethodSecurityInterceptor "> <property name=3D"authenticationManager"><ref=20 bean=3D"authenticationManager"/></property> <property name=3D"accessDecisionManager"><ref=20 bean=3D"decisionManager"/></property> <property name=3D"afterInvocationManager"><ref=20 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_AFTER_ACL= _READ com.vivakos.vps.service.content.TopicService.getTopicChildren=3DTOPIC_AFTER= _ACL_READ </value> </property> </bean>=20 And as far as I can see - when using TransactionProxyFactoryBean, all three= =20 methods get applied correctly. i.e. integration tests that test the 'get',= =20 'getTopicList' and 'getTopicChildren' all work properly.=20 But when changing to use ProxyFactoryBean, the 'get' method integration tes= t=20 fails (the interceptor apparently is not called), while 'getTopicList' and= =20 'getTopicChildren' work integration test works fine. The only differnence i= n=20 how the methods that are tested is that 'get' is defined in an higher level= =20 interface (Service) instead of (TopicService). The integration test calls= =20 topicService.get() .... I'm hoping that someone can help shine additional light on this difference= =20 in behavior with the interceptors, and what I might be doing wrong? Thanks in advance, -tim |