Struts2.1.6与spring2.5.5集成

把struts2-spring-plugin-2.1.6.jar添加到classpath中，struts2会自动扫描struts-plugin.xml文件，该文件自动注册了com.opensymphony.xwork2.ObjectFactory，完成和spring的集成。 (Struts2与Spring的集成，其实，只要一个JAR就可以自动完成两者的集成。 集成后，Struts2会把它自己的Action控制器交给Spring来创建和管理，需要在Spring配制文件中配制Action控制器Bean,并且在Struts2的配制文件中引用这个Action控制器Bean ID ，而不再用Action控制器的实现类了。而在集成前，是由Struts2框架自动创建和管理Action控制器对象)

Struts2与Spring完成集成后，客户请求的流程发生了微妙的一些变化（主要就是因为，Struts2的Action控制器交给了Spring来创建和管理了）。
Spring插件提供了一种伪Action,当我们在struts.xml文件中配置Action时，通常需要指定class属性，该属性就是用于创建Action实例的实现类。但Spring插件允许我们指定class属性时，不再指定Action的实际实现类，而是指向Spring容器中的Bean ID。
通过上面的方式，我们发现了这种整合策略的关键：当struts2将请求转发给指定的Action时，Struts2中的该Action只是一个“傀儡”，它只有一个代号，并没有指定实际的实现类，当然也不可能创建Action实例，而隐藏在该Action下的是Spring容器中的Actoin实例----它们才是真正处理用户请求的控制器。这就实现了让核心控制器调用Spring容器中的Action来处理用户请求。
在这种整合策略下，处理用户表示的Acton由Spring插件负责创建，但Spring插件创建Action实例时，并不是利用配置Action时指定的class属性来创建该Action实例，而是从Spring容器中取出对应的Bean实例完成创建。





注意这里的bean name是adminAction，再看Bitrac\src\admin.xml里的class="adminAction"，Spring和Struts的结合点就在这里，后台处理这一结合的是struts2-spring-plugin-2.1.2.jar。如果不使用spring，在admin.xml中将是class="com.albertsong.bitrac.action.AdminAction"。