Dale, honestly, I was being lazy and giving him the "quick" solution to his problem. The thing about that error is that it is pretty obvious what needs to be done, if you're versed in the arts of proxy class generation. Most people don't really look into what spring is doing behind the scenes, they are just happy that they get the service implementation they specify. In this case, spring recognizes that the class needs intercepted via AOP so it proxies it, but as you mentioned, since the spring default is to use JDK proxies, only methods inherited from from an interface will be exposed (limitation/feature [toemaytoe/toemahtoe] of jdk proxies).
IMO, choosing jdk over cglib or vice versa is pretty much a coin toss... You could argue the technical merit and the value of the requiring interfaces to be implemented. But, to me, it really comes down to the fact that none of that really matters since you are simply asking spring to choose one or the other. Maybe JDK proxies are a better design choice, but you don't really have any say as to how Spring designs/implements the proxies... The Spring code could be really bad for all we know. So, I just treat it like a black box, if I am trying to intercept action method invocations, I just let spring use CGLIB because I am aware of the limitation/feature of JDK proxies. Creating an interface that exposes the 'input1' method in his case sort of defeats the purpose of using AOP... I mean, if you have to change your code to use AOP, why not just change the code to execute the logic you want? -Wes On Tue, Aug 18, 2009 at 10:00 AM, Dale Newfield<d...@newfield.org> wrote: > Wes Wannemacher wrote: >> >> If you're using AOP, you'll need to tell spring to proxy classes using >> CGLIB rather than dynamic JDK proxies... To do so, you'll have to add >> the cglib jars to your project and add the following to your >> applicationContext.xml -> >> >> <aop:config proxy-target-class="true" /> > > http://static.springsource.org/spring/docs/2.0.x/reference/aop-api.html#aop-pfb-proxy-types > > I understand if the OP has methods in the implementation that are not in the > interface that the interface based proxy won't have those methods. > > I'm unclear, though, whether your advice is a general suggestion, or just to > solve this specific problem (without the (IMHO) more advisable solution of > adding input1() to the implemented interface). Without the OP's problems, I > don't understand what the benefit of having the auto-generated proxies > extend the class rather than implement the same interfaces would be. It > seems that there are many more pitfalls (with private/protected, whether or > not the proxy calls super() methods (before then calling them on the wrapped > bean), etc.) with this solution, no? > > Sorry to ask spring questions on a struts list, but I'm just trying to > understand the already proffered advice. > > -Dale > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > > -- Wes Wannemacher Head Engineer, WanTii, Inc. Need Training? Struts, Spring, Maven, Tomcat... Ask me for a quote! --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
