第一种整合方式：

1.在Struts配置文件中增加一个Spring插件配置，其它配置不变。这个插件的作用是web服务器启动时即创建ApplicationContext上下文实例，并将其加载到ServletContext实例（即jsp的内置对象application）中。

2.用户Action不再从struts框架的Action基类继承，而从Spring提供的Action基类继承，这个类是org.springframework.web.struts.ActionSupport，这个类不仅提供了Struts Action 所有功能，而且提供了获取ApplicationContext上下文实例的方法，我们所需要的业务对象即从ApplicationContext实例获得。

3.其它方面与在struts下开发一样。

弊端（现在我们发现在第一种整合方式中，我们的Action类直接使用Spring特定的类ActionSupport，显然这使action代码与Spring紧密耦合，另外，action类也负责查找由

Spring管理的Bean,这违背了反向控制(IoC)的原则。）

第二种整合方式:

１．现在介绍Spring提供的第二种与Struts集成的方式。在这种方式下，我们的Action仍然继承的是Struts提供的Action基类,业务对象（bean）以成员属性的方式定义，并提供相应的set方法，使用Spring的IoC方式将业务对象注入到Action中，从而不需要通过编码在应用上下文中查找．

２．实现原理：我们知道struts的中央控制器是ActionServlet类，所有请求都经由这个类进行协调控制，而在这个类的内部是将控制任务通过调用另外一个类RequestProcesser而实现的，同时struts还允许用户继承RequestProcesser ，重写自己的控制实现，并在配置文件中指定通过那个RequestProcesser实现控制。Spring正是利用了这一原理，提供了自己的RequestProcesser，这个类会将会根据Spring和Action配置文件实现Action的实例化、业务对象的注入，访问地址到Action的映射。

第二种整合方式的实现步骤

1.在struts配置文件中增加上下文插件配置（与第一种方式相同）

2.在struts配置文件中增加RequestProcesser配置：

<controller processorClass="org.springframework.web.struts.DelegatingRequestProcessor">
</controller>

3.在Spring配置文件中将Action做为bean进行配置：

<bean name="/doAddPerson" class="ibmsoft.action.DoAddPersonAction">
  <property name="service"><ref bean="service"/></property>
</bean>

值得注意的是：a）bean的配置中没有使用id属性，而是使用name属性，其原因是id属性的值不允许出现“/”，因此使用name属性，二者的作用是一样的。b）bean的名字是Action的映射地址名。

4.其它方面不用变，一切OK。