通常在设计中往往会要求同一个Action来处理客户端发出的不同请求,如下

　　Java代码

　　删除一个成员

　　添加一个成员

　　碰到该类问题,在struts中得到了很好的处理,如下

　　sturts-config.xml配置

　　Java代码

　　

　　

　　

　　

　　

　　UserAction代码

　　Java代码

　　public class UserAction extends DispatchAction {

　　public UserAction(); {

　　}

　　public ActionForward deleteUsr(ActionMapping mapping, ActionForm form,

　　HttpServletRequest request, HttpServletResponse response);

　　throws Exception {

　　......

　　}

　　public ActionForward addUsr(ActionMapping mapping, ActionForm form,

　　HttpServletRequest request, HttpServletResponse response);

　　throws Exception {

　　......

　　}

　　在struts中DispatchAction 很好的解决了此类问题。可是当spring+sturst结合的过程中，如果碰到上面的问题，首先改写struts-config.xml

　　Java代码

　　

　　

　　

　　

　　显而易见，在面向SS组合的配置方式中，用spring提供的DelegatingActionProxy 作为Action

　　的type属性。DelegatingActionProxy同样是org.apache.struts.action.Action的一个子类，它将

　　把调用请求转交给真正的Action实现.如下

　　Java代码

　　

　　

　　

　　

　　

　　DelegatingActionProxy则实现了针对实际Action的调用代理，struts最终调用的将是由spring管理的Action实例,这样客户端发送的各种请求就可以用spring的Ioc设计思想实现了。可是在我发现并不是我预想的那样结果，总是出现source not found。程序无法执行下去，原因很简单就是在

　　Java代码

　　

　　

　　

　　

　　的时候，并没有像struts那样传递一个参数parameter="operation"，所以肯定找不到执行哪一个Action的type,我猜想DelegatingActionProxy代理返回的类型一定不会是DispatchAction，于是我查看了DelegatingActionProxy的源码

　　Java代码

　　public class DelegatingActionProxy extends Action {

　　/**

　　* Pass the execute call on to the Spring-managed delegate Action.

　　* @see #getDelegateAction

　　*/

　　public ActionForward execute(

　　ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response);

　　throws Exception {

　　Action delegateAction = getDelegateAction(mapping);;

　　return delegateAction.execute(mapping, form, request, response);;

　　}

　　......

　　}

　　果然是继承了Action，此时我要实现上述描述的操作，DelegatingActionProxy代理应该如何处理呢？

关键字:ss delegatingactionproxy 代理 问题 通常在 设计 | 来源:互联网 | 责任编辑:系统管理员 | 最后编辑:2012年01月07日 10时56分01秒