Menu
▾
▴
RE: [Springframework-developer] Trying again. Difference in advised behavior btwn ProxyFactoryBean and TransactionProxyFactoryBean??
|
From: Tim K. <tim...@gm...> - 2005-09-13 14:15:20
|
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 |
