Struts 弱点

没有事件模型 说明 Struts 紧密地和HTTP的请求-响应模型结合，这限制了开发人员更好地处理事件

调试 说明 不支持自动调试（除错），开发人员不得不手工创建“断点”，并向容器的记录系统写标准输出
没有缺省的数据模型或 者具体的推荐 说明 访问持久数据模型的任务留给了开发人员

单一ActionServlet  说明 在一个应用中只可以使用一个单一的ActionServlet，这个限制可能导致配置冲突

需要理解Struts组件   说明开发人员需要理解一些特殊的类以及他们如何交互。

不能提供优先技术支持  说明 ASF是个志愿者组织，没有全职人员提供可担保的响应

Mailing list已经成为知识的障碍  说明 Struts 有一个日益增长的邮件列表，但要在其中找到最好的建议非常困难。

 

正式发布版本并不快速 说明 Struts正式发布版相对于其它项目来说显得慢了。开发人员必须经常检查“每日构件”或的最新改进。

 

i18n  说明:限制Struts 的消息资源对建立国际化的资源和错误信息非常好，但不适合于处理大文本块
JSP mindset 说明 因为使用MVC架构, 使得资源对所有表现层都是有效的。这对JSP来说是个长期的Struts弊病。

JSP异常的本地化 说明 很多系统级消息，象JSP异常，都没有本地化，通常显示为英语标记属性冗长 许多标记扩展要求很多参数，对编程来说显得很笨

perform 和 execute 方法签名 说明:Struts 架构的关键是将请求委托给一个 Action类或者叫分发者dispatcher。Action 类是Struts支持的唯一分发者，并且只有通过其perform 方法来调用。这将应用限制在只能和perform 方法传递的数据一起工作。即使有办法超出这个限制， perform 方法也是个瓶颈。一个通常的请求要求ActionServlet组装几个ActionForm。但是因为 perform 接受单个ActionForm 参数，如果不经过较大的框架革新是不可行的。Struts 1.1 添加了一个execute方法，它有助于改善perform的其它主要缺陷：因为会返回异常。然而，其它后果仍然存在。

模糊的术语 说明:Struts 框架在明显的增长。而给与一些应用选项和类的名称却容易让人混淆。例如，web.xml “ 中的validate” 选项却和Action对象的validate 方法无关，而和如何解析配置文件相关。同样，神秘的 “ null”选项则表示当消息关键字未找到时，是否返回一个错误信息。有一个趋势是在类层次体系中使用复合名称。在Action包中的每个类都有个前缀为 “Action,”这却是多余和容易混淆的。同时，在Struts配置文件中， ActionMappings 定义的元素名是“ Action” 而不是“ ActionMapping” 。如果开发人员引用一个“ action,” 很难区别它们是指Action 类或是配置类的ActionMapping。在 Struts 配置中，“ name” 字段标识ActionForward 和ActionForms。“ path” 字段标识 ActionMapping。action-mapping 元素的“name” 属性则指出使用哪个ActionForm 。 ActionForward 的URI字段也称为 "path”，但可以包括伴随path的查询组件。到ActionMapping 的 “ path”不包括servlet 样式, 象 *.do, 但是ActionForward 的path 却包括 *.do 扩展名。应用资源其实是真正的消息资源。等等。
凡此种种，这些小矛盾可以把一些新手搞糊涂，并且使框架难以学习