SSH流行很久了，一直看到官方文档和网上都在讲如何整合SSH，讨论各种整合的优缺点。今天我比较闲，也用我的一些想法来试着整合这三个最流行的框架。

本次所用版本为：Struts 1.3.9   Spring 2.5   Hiberante 3.2
开发工具和环境为：Eclipse 3.3+MyEclipse 6.0+JBoss 4.2+Tomcat

用SSH时，我们的架构自然就会分成三层，即表现层，逻辑层和持久层，按照Martin Flower的指导思想，耦合越少越好，下层为上层提供服务，这也是Rod开发Spring的指导思想之一，所以我首先想到的就是如何减少到最低的耦合。
根据Spring 2.0官方文档中推荐的做法，Spring与Struts1.x集成，有采用代理类的方式，也有用ActionSupport的方式，但是我认为这两种方式无疑都有很强的侵入性和依赖性，这与Spring的思想有些矛盾。
我采用AutowiringRequestProcessor来做，这个类会自动为你装载你所需要的Service，根据其Java Doc的提示，其默认是byType匹配的，当然你也可以用byName的方式，我认为以Type的方式就OK了。来看看两个配置文件吧，先来看看Struts的配置文件struts-config.xml：

 1   
 2   
 3  
 4   
 5       
 6           
 7       
 8  
 9       
10       
11       
12           
14       
15     
16       
18  
19       
20   
21  
22  
这个文件中可以发现，跟没有与Spring集成时就一点不一样，多了一行：
 

再来看看Spring的配置文件applicationContext.xml：

 1   
 2   
 3  
 4   
 5  
 6       
 8           
 9               classpath:hibernate.cfg.xml  
10           
11       
12     
13       
15           
16               
17           
18       
19  
20       
21           
22               
23           
24       
25   
26  
这里面也没有多余的内容，不会出现代理方式时，多份XML同时配置的问题，减少了维护量。
同时，你会发现，我并没有把Hibernate的具体配置放在这里面，而是用Hibernate自身的配置来管理。

这样的话，我们三层之间的依赖性会降到较低，两头可以任意换到其中的某一层。

顺便要说的是，常见的书籍上面发现往往不会有如此深入的探讨，难道是怕初学者看不懂吗？
另外，对于一个架构来说，要解决的问题决不是指这些，通常我们可以采用RUP的4＋1视图的方法去考虑架构的方方面面。我们也可以从以下一些方面来各个击破：安全性，数据输入输出的校验与转换，国际化，LOG，异常处理，异构系统整合，后台运行程序等等。如果是多个数据库，我们还需要更多的考虑事务控制。

我想我后面会去完善这个整合，并实现一个Demo，作为小的简单的项目快速开发的基础。



整合时遇到过如下问题：
问题1：启动时出现 “严重: Error listenerStart ”
这个问题，网上有很多解决办法：
有一种最简单的解决办法是把用Listener初始化Spring改为用Servlet初始化Spring，但这样的方法不太好，一是没有找到根源，二是可能会带来新的问题。
比较好的一种解决办法是，加上Log4J的相关配置，然后再启动时，就会出现各类详细信息，这样可根据具体信息再来解决，一般可能是DataSource配置，或环境配置有问题。
参考网址：http://hi.baidu.com/xht314/blog/item/808ecf13c1dd1820dd5401af.html

问题2：遇到“Required extension qdox not found”这样的提示
网上也有解答，我用的方法是直接把commons-attributes-compiler.jar这个包去掉。当然如果你要用到这个包的话，可以参考下面这个地址：
http://hi.baidu.com/sky_lei/blog/item/77ee17085543b232e8248824.html

问题3：Struts包与Spring包冲突的问题
我遇到包有冲突，换成Struts需要的优先就OK了，现在的JAR档越来越麻烦了，很多项目的JAR档都被开发人员搞得乱七八糟，看来Maven是个好东西，至少思想是好的，可能下一步需要研究一下。