3

私はTomcatアプリケーションをかなり巨大にしています。ビジネスに非常に重要です（実際の金儲け）。しかし、それはレガシーJavaコードです。意味、JSP（多くのJavascript、Javaコードを含む）、サーブレット（数千行のコードを含む）など。このくだらないコードから離れたいと思います。これで、別のアプリケーション（異なる目的、異なる機能）に対する要求が発生しました。別のコンテキストルートで必要です/NewAppは、レガシーアプリケーションのディレクトリ構造の下で言うことができます。ミニサイトのように。別のURLがあり、いくつかの仮想ホストにサービスを提供している可能性もあります。

レガシーコードを拡張したくありません。私たちは、より良いテクノロジーとより良いやり方に移行したいと考えています。私たちはSpring（タイル、ジャクソンなど）と、Portletを含むSpringが提供するすべてのものを強く望んでいます。そのため、DispatcherServlet / ContextLoaderListener / configLocationなどをレガシーアプリweb.xmlに取り込み、Springアプリを並べて使用する可能性を検討しています。

主な理由は、新しいアプリがレガシーサービスとライブラリに深刻な依存関係にあることです。

  1. この平和な共存は可能ですか？
  2. 私たちが直面する可能性のある課題は何ですか？
  3. 構成例を教えてください。

残念ながら、それらを分離することはできません。これに対するあなたの洞察に感謝します。

ありがとうございました！！

4

1 に答える 1

4

少し前に、適度に大きなアプリケーションを EJB 2.1 から Spring に移行する際に、同様の使用例を経験しました。長い間、Spring Bean は EJB と共存していました。Spring Bean が EJB に依存するように、最初に依存関係階層でリーフを選択していましたが、その逆はありませんでした。これは見事に機能し、Spring プロキシと依存性注入のおかげで、Bean は他の Bean と同じように EJB を呼び出していました。

同じアプリケーションで、新しいページ用に Struts 1 と Wicket の両方を使用し (くそー、Struts ページ内に Wicket iframe さえありました!)、JPA と並行して従来の JDBC ベースの永続化ソリューションを使用していました。それはすべてうまくいきました。

注意事項:

  1. これはまだ 1 つのアプリケーションです。バックエンド キャッシュに注意してください

  2. レガシー サービスを Spring Bean のように扱います。いくつかのブリッジ/プロキシ/アダプターを構築し、他の Bean を注入するのと同じようにレガシー サービスを注入します。レガシー API に依存しない (いくつかのシングルトン、ファクトリ、JNDI ルックアップを想像します)

  3. 古いものと新しいものの境界をテストするのは難しいでしょう。たくさんの嘲笑に備えてください。

  4. Web セキュリティについて考えてみましょう。両方の「アプリケーション」を簡単に統合できますか?

  5. 古いコードを新しいテクノロジに完全に書き直すことはできません。その頃には、新しいテクノロジーも古くなり、新しい開発者が登場します。しかし、古いコードの品質を毎回少しずつ改善してみてください。リファクタリングは奇跡を起こすことができます!

構成に特別なことは何もありません。Spring がアプリケーション全体を支配しなければならないというのは誤解です。軽量で薄いアドオンとして使用でき、アプリケーションの残りの部分に隣接します。

于 2012-10-24T17:13:41.407 に答える