struts2的缺点

一、 转到展示层时，需要配置forward，每一次转到展示层，相信大多数都是直接转到jsp，而涉及到转向，需要配置forward，如果有十个展示层的 jsp，需要配置十次struts，而且还不包括有时候目录、文件变更，需要重新修改forward，注意，每次修改配置之 后，要求重新部署整个项目，而tomcate这样的服务器，还必须重新启动服务器，如果业务变更复杂频繁的系统，这样的操作简单不可想象。现在就是这样， 几十上百个人同时在线使用我们的系统，大家可以想象一下，我的烦恼有多大。
    二、 Struts 的Action必需是thread－safe方式，它仅仅允许一个实例去处理所有的请求。所以action用到的所有的资源都必需统一同步，这个就引起了 线程安全的问题。
    三、 测试不方便. Struts的每个 Action都同Web层耦合在一起，这样它的测试依赖于Web容器，单元测试也很难 实现。不过有一个Junit的扩展工具StrutsTestCase可以实现它的单元测试。
    四、 类型的转换. Struts的 FormBean把所有的数据都作为String类型，它可以使用工具Commons- Beanutils进行类型转化。但它的转化都是在Class级别，而且转化的类型是不可配置的。类型转化时的错误信息返回给用户也是非常困难的。
    五、 对Servlet的依赖性过强. Struts处 理Action时必需要依赖ServletRequest 和ServletResponse，所有它摆脱不了Servlet容器。
    六、 前端表达式语言方面.Struts集 成了JSTL，所以它主要使用JSTL的表达式语言来获取数据。可是JSTL的表达 式语言在Collection和索引属性方面处理显得很弱。
    七、 对Action执行的控制困难. Struts创 建一个Action，如果想控制它的执行顺序将会非常困难。甚至你要重 新去写Servlet来实现你的这个功能需求。
    八、 对Action 执行前和后的处理. Struts处 理Action的时候是基于class的hierarchies， 很难在action处理前和后进行操作。
    九、 对事件支持不够. 在struts中， 实际是一个表单Form对应一个Action类(或 DispatchAction)，换一句话说：在Struts中实际是一 个表单只能对应一个事件，struts这 种事件方式称为application event[align=left][/align]，application event和component event相比是一种粗粒度的事件。