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