主要问题：如果我的应用程序当前使用的是 Struts 1.x——并且我正在考虑迁移到 Spring-MVC 或 Struts2 以用于 MVC 框架——是否有任何一个可以更容易地从 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 类的需求，并尽可能使用基于注释的配置等）但保持整体经典-MVC 风格（即目前对过渡到 JSF、Tapestry、GWT、Flex、Play 等不感兴趣。我知道这些是非常不同的东西 - 将它们混为一谈只是为了给出一个总体思路。）另外，愿望是选择具有合理牵引力/动力的东西 - 因此出于这个原因将条纹排除在外。这似乎只会让 Spring-MVC 和 Struts2 成为竞争者（尽管如果还有其他具有类似风格和强大行业牵引力的东西 - 我们当然会考虑）
当然，切换到其中任何一个都需要减少工作量 - 但计划是在模块化级别上进行。出于这个原因，如果这些支持 Struts 1.2 的标记库中的任何一个 - 它会使切换/测试更容易（因为我们可以在新 API 中编写特定模块的“控制”实现 - 并让第二台服务器运行旧的 Struts1 .2 使用相同的 jsps 实现。QA 测试在某种程度上将是“苹果对苹果”。这是否有意义，或者这种方法（如果可行的话）会导致比它解决的问题更多的问题？
另外，如上所述，虽然我的主要问题是关于使用 Spring-MVC 或 Struts2 运行 struts1.2 的标记库 - 我也对 Struts2-vs-Spring-MVC 的任何其他迁移优势感兴趣。