主要问题：如果我的应用程序当前正在使用Struts 1.x - 并且我正在考虑迁移到用于MVC框架的EITHER Spring-MVC或Struts2 - 那么是否有任何一个可以更容易从Struts1.2迁移？
为了澄清，我不是在问SpringMVC或Struts2总体上是否更好（在SO上有许多现有的Q来解决这个问题） - 从Struts1.2迁移到哪一个更容易。
从迁移的角度来看，我最感兴趣的一点是：继续的可能性 （在一开始的时候） 在JSP页面中使用struts1.x的taglib，同时在后端更改为Struts2（或SpringMVC）的API。 （换句话说，这些框架中的任何一个都可以支持Struts1.x的taglib作为插件）吗？ [注意：这不是一个长期的解决方案 - 但会减少集成的痛苦，因为JSP不需要立即重写。我认为这个问题是有道理的 - 如果没有，请说明为什么]
话虽如此，我当然对任何其他迁移优势感兴趣。
一些背景：
我正在开发一个应用程序，其MVC层是通过Struts 1.2编写的。我们也在使用Spring IOC - 尽管该应用程序目前还没有Struts层和Spring的DI工具之间的强大集成。 （注意：这是我们在重构时计划纠正的内容，但我的理解是通过一些规划 - 即使使用Spring IOC + Struts2组合也可以正确/有效地完成。）
作为改进/重构代码库的一部分 - 我们希望升级到更现代的MVC框架（以便消除对Action / Form类的需求，并在可能的情况下使用基于Annotation的配置等）但保持整体经典-MVC风格 （即目前没有兴趣跳到JSF，Tapestry，GWT，Flex，Play等等。我明白这些是非常不同的东西 - 将它们混为一谈只是为了给出一个大致的想法..） 此外，我们的愿望是采用具有合理牵引力/动力的东西 - 因此裁决Stripes出于这个原因。这似乎只是让Spring-MVC和Struts2成为竞争者（尽管如果有其他类似风格和强大的行业牵引力 - 我们肯定会考虑它）
可以切换到其中任何一个都需要下降工作量 - 但计划是在模块化水平上进行。出于这个原因，如果其中任何一个支持Struts 1.2的taglib - 它将使切换/测试更容易（因为我们可以在新API中编写特定模块的“Control”实现 - 并让第二个服务器运行旧的Struts1 .2使用相同的jsps实现.QA测试在某种程度上将是“苹果到苹果”。这是否有意义，或者这种方法（如果可行的话）会导致比解决更多的麻烦？
另外，如上所述，虽然我的主要问题是使用Spring-MVC或Struts2运行struts1.2的taglib - 我也对Struts2-vs-Spring-MVC的任何其他MIGRATION优势感兴趣。