Menu
▾
▴
Re: [Springframework-developer] Trying again. Difference in advised behavior btwn ProxyFactoryBean and TransactionProxyFactoryBean??
|
From: Dmitriy K. <dko...@ru...> - 2005-09-13 01:12:04
|
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 > |
