主な質問：私のアプリが現在Struts 1.xを使用していて、MVCフレームワークとしてSpring-MVCまたはStruts2のいずれかに移行することを検討している場合、Struts1.2からの移行を容易にするものはありますか？
明確にするために、私はSpringMVCとStruts2のどちらが全体的に優れているかを尋ねていません（これに対処するSOには既存のQがいくつかあります）-どちらがStruts1.2から移行しやすいかだけです。
移行の観点から私が最も興味を持っている点は、バックエンドでStruts2（またはSpringMVC）のAPIに変更しながら、JSPページ内でstruts1.xのtaglibを（最初に）使用し続ける可能性です。（言い換えると、これらのフレームワークのいずれかがプラグインとしてStruts1.xのtaglibをサポートできますか？）[注：これは長期的な解決策として意図されたものではありませんが、JSPをすぐに書き直す必要がないため、統合の問題が軽減されます。この質問は理にかなっていると思います-そうでない場合は、理由を説明してください]
そうは言っても、私はもちろん他の移行の利点に興味があります。
いくつかの背景：
私はMVCレイヤーがStruts1.2を介して記述されているアプリに取り組んでいます。また、Spring IOCも使用していますが、アプリには現在、StrutsレイヤーとSpringのDI機能が強力に統合されていません。（注：これはリファクタリング時に修正する予定ですが、少し計画を立てれば、Spring IOC + Struts2の組み合わせを使用している場合でも適切/効率的に実行できると理解しています。）
コードベースの改善/リファクタリングの一環として、より新しいMVCフレームワークにアップグレードしたいと思います（アクション/フォームクラスの必要性を排除し、可能な場合はアノテーションベースの構成を使用するなど）が、全体的なクラシックを維持します-MVCスタイル（つまり、現在JSF、タペストリー、GWT、Flex、Playなどに飛躍することに興味がありません。これらは非常に異なるものであることを理解しています-一般的なアイデアを与えるためにそれらをまとめます。）また、欲求は、合理的な牽引力/勢いで何かを行うことです-そのため、Stripesを除外します。これは、Spring-MVCとStruts2を競合他社として残すだけのようです（ただし、同様のスタイルで業界の牽引力が強いものが他にある場合は、確かにそれを検討します）
これらのいずれかに切り替えるには、かなりの量の作業が必要になることは当然ですが、計画では、モジュールレベルでそれを行うことです。そのため、これらのサポートされているStruts 1.2のtaglibのいずれかがあれば（新しいAPIで特定のモジュールの「制御」実装をコーディングできるため）、切り替え/テストがはるかに簡単になり、2番目のサーバーで古いStruts1を実行できます。 .2同じjspsを使用した実装QAテストは、ある意味で「apples to apples」になります。これは理にかなっていますか、またはこのアプローチ（実行可能である場合でも）は、解決するよりも多くの頭痛の種につながりますか？
また、前述のように、私の主な質問は、Spring-MVCまたはStruts2のいずれかでstruts1.2のtaglibを実行することですが、Struts2-vs-Spring-MVCの他の移行の利点にも興味があります。