struts2出现的原因：struts1的缺陷
1.支持的表现层技术单一
Struts1只支持JSP作为表现层技术，不提供与其他表现层技术，例如Velocity、freemarker等技术的整合。这一点严重约束了Struts1框架的使用，对于目前的很多JavaEE应用而言，并不一定使用JSP作为表现层技术。
虽然Struts1处理完用户请求后，并没有直接转到特定的视图资源，而是返回一个ActionForward对象（ActionForwad理解为一个逻辑视图名），在struts-config.xml文件中定义了逻辑视图名和视图资源之间的对应关系，当ActionServlet得到处理器返回的ActionForward对象后，可以根据逻辑视图名和视图资源之间的对应关系，将视图资源呈现给用户。
从设计层面上来看，不得不佩服Struts1的设计者高度解耦的设计：控制器并没有直接执行转发请求，而仅仅返回一个逻辑视图名----实际的转发放在配置文件中进行管理。但因为Struts1框架出现的年代太早了，那时候还没有FreeMarker、Velocity等技术，因而没有考虑与这些FreeMarker、Velocity等视图技术的整合。
Struts1设计非常优秀，但是由于历史原因，他没有提供与更多视图技术的整合，这严重限制了Struts1的使用。
2.与Servlet API严重耦合，难于测试
因为Struts1框架是在Model2的基础上发展起来的，因此它完全基于Servlet API的，所以在Struts1 的业务逻辑控制器内，充满了大量的Servlet API。
看下面的Action代码片段：
当我们需要测试上面的Action类的execute方法时，该方法有4个参数：ActionMapping、ActionForm、HttpServletRequest、HttpServletResponse，初始化这4个参数比较困难，尤其是HttpServletRequest和HttpServletResponse两个参数，通常由Web容器负责实例化。
因为HttpServletRequest和HttpServletResponse两个参数是Servlet API，严重依赖于Web服务器。因此，一旦脱离了Web服务器，Action的测试非常困难。
3.代码严重依赖Struts1 API，属于侵入式设计
正如从上面代码片段中多看到的，Struts1 的Action类必须继承Struts1的Action基类，实现处理方法时，又包含了大量Struts1 API：如ActionMapping、ActionForm和ActionForward类。这种侵入式设计的最大弱点在于一旦系统需要重构时，这些Action类将完全没有利用价值。
摘至：Struts2 权威指南