在web.xml文件里配置一个派遣器ServletDispatcher，以接收所有以action结尾的url请求。并进行http请求调度处理.
<servlet>
   <servlet-name></servlet-name>
   <servlet-class>com.opensymphony.webwork.dispatcher.ServletDispatcher</servlet-class>
</servlet>
<servlet-mapping>
   <servlet-name>webwork</servlet-name>
   <url-pattern>*.action</url-pattern>
</servlet-mapping>
当ServletDispatche调度器接收到一个.action结尾的请求时，会调用ServletDispatche类的service方法进行处理,该方法最终是创建一个ActionProxy对象，并通过执行ActionProxy中的execute方法来
调用所请求的Action的execute方法.之前要执行一些方法来创造条件：创建Action上下文===>从request中获得值堆栈stack===>创建ActionProxyFactory对象，并初始化一个DefaultActionProxy对象====>通过DefaultAction的构造函数调用ConfigurationManager获得当前请求的Action在xwork.xml中的配置信息====>DefaultActionProxy中的prepare方法通过创建一个ActionInvocation对象来实现对请求action的调用。

AroundInterceptor拦截机-->
DefaultActionInvocation中有一个数组维护了拦截机的执行顺序：
1、StaticParametersInterceptor, 2、ParametersInterceptor, 3、WebWorkConversionErrorInterceptor
4、ModelDrivenInterceptor 5、ExternalReferencesInterceptor
6、StaticParametersInterceptor 7、parametersInterceptor, 8、WebWorkConversionErrorInterceptor
9、ModelDrivenInterceptor 10、ValidationInterceptor
注：这里1、2、3、4拦截机执行了两次，为什么会执行两次呢?
疑问：这里的执行顺序和webwork-default.xml中的<interceptors>配置有何关联?

Action ---> 根据Action实现相应的Action,ModelDriven接口调用基类的
ParametersInterceptor中：
      final Map parameters = ActionContext.getContext().getParameters();

从AroundInterceptor的context中取出页面提交字段的名称和值,然后它会先把stack.pus(modelDriven.getModel()); modelDriven.getModel()放到CompoundRoot中(CompounRoot是一个ArrayList)上面提到有四个拦截机执行两次，因为第一次要push进去一个空的对象，方便填值，第二次放的是填充好的对象。也就是Action中getModel()的对象。把值从parameters 设置到OgnlValueStack的CompoundRoot的第一个下标中的Action里的getModel()对象里code:stack.setValue(name, value);name对应的是getModel()对应的字段，value为要填充的值.

     摘要:    最近偶参与一个J2EE项目，应用架框是struts+spring! 持久层用hibernate,由于业务需要，业务数据来源来二个不同的数据库数据库是Orcale,版本是9.0.1.0.0。由于采用容器管理事务(CMT),对于Spring,一般普通业务应用我用声明式事务，因为这样让代码清洁一点，只有对于特殊的业务我才用编程式事务，如大批量更新时调用存储过程。对于WebLog...  阅读全文          POJO(plain old java Object)[译：简单初始Java对象]。它简单(因为只有set/get方法)吗？或是我们把应该把它弄得复杂点(带点业务判断)？究竟它在我们J2EE应用中扮演一个什么样的角色呢？一个Anemic Domain Model，Rich Domain Model, DTO, O/R mapping Entity........！以前我的系统中POJO都是一个贫血的模型，只有set/get方法！它的职责就是把前端页面的数据从formBean中转移过来(用反射)，作为持久层的对象。这里POJO有两个角色，一个角色是传送数据，另一个是角色是PO(持久对象)。一段时间后我发现这样做效率低下，想像一下有些业务处理，如一个银行帐户的pojo,里面有一个金额和利息字段，这个金额是通过一些公式计算后得出来的，开始时我们在业务层里把金额算出来后set到帐户pojo金额字段里。我开始思索把一些都是计算或者纯逻辑的东西pull Up到pojo中。这时候我的pojo变成一个Domain Object。尽管不是一个Rich的Domain Model,但毕竟前进了一小步。再后来用到了webwork2,由于webwork2里没有了struts formBean，使用拦截机设值，ModelDriven模式下我的持久Entity就是一个formBean和po的结合,　在ACTIO中它是一个有值的VO，在DAO实现层变成一个PO。在这里我的pojo继承了O/R Entity类，并把合适的业务层的代码都移到相应的了Pojo中，当然没有持久层的代码。这样我的系统的部分pojo变成了Rich Domain Model。在Ejb下，由会话门面管理对POJO业务对象访问对比起笨重的entity bean有更高的效率和可移植性。尽管Ejb下的POJO不能享受entity bean的CMP策略，但有了spring 的IOC后，一切变得可配置了！POJO还有很重要的一个优势就是pojo中的业务可以脱离具体容器运行测试！在这里,pojo是贫血还是冲血应该取决于你的业务应用，记住：不要把简单的问题搞复杂了，但把复杂的问题分解成简单的问题一直就是我们追求的！