Netty/NIO ベースのサービスを構築しており、このサービスを運用環境に展開することを検討しています。サービスをデプロイする標準的な方法は、WAR として Tomcat 内にデプロイすることです。
ここで同じアプローチを提案したところ、Netty と Tomcat の両方がサーバーであり、「あるサーバーを別のサーバーでホストするのは意味がない」ため、「実行すべきではない」という叫び声と苦情が寄せられました。
展開の問題が完全に解決され、他のコードを書く必要がなくなるので、私にとっては完全に理にかなっています。なぜそれはそんなに大きな「いいえ」なのですか？
Tomcatが提供する動的なWARのデプロイとアンデプロイは、Webアプリケーション用に設計されています。TomcatにデプロイしようとしているNettyアプリケーションは、Webアプリケーションではなく、VMメモリのみを共有する別個のサーバーです。これは、TomcatがOSGiなどの一般的なマイクロカーネルに再利用されたことを意味します。
しかし、それは大きな問題ではないと思います。あなたの会社はWARを標準の展開メカニズムとして使用しているので、それを再利用することをお勧めします。Tomcatはすでにそれらを提供しているので、リモートシャットダウンのようないくつかの管理機能を書く必要さえありません。あなたがする必要があるのは、展開されていないときにすべてのリソースが解放されていることを確認することです。
ただし、このアプローチが気に入らない人もいるかもしれません。理想的には、Tomcatでさえモジュールとしてデプロイされ、マイクロカーネルがTomcatの代わりに直接WARを管理する、あらゆるアプリケーション（別名マイクロカーネル）をデプロイおよび管理するための共通のインフラストラクチャが必要です。しかし、それは長い道のりです。
とても理にかなっています。実際、Tomcat で Java 電子メール サーバーを実行しています。
Tomcat には、アプリケーションを収容するためのいくつかの大きな利点があります。
現在、Netty、Mina、またはイベント駆動型のネットワーク テクノロジでは、ほとんどの MVC フレームワークを使用できません。実際、ほとんどの Java エンタープライズ フレームワークを使用することはできません。これは、多くのことが要求ごとのスレッドに依存しているためです (トランザクション、セキュリティなど)。
Tomcat で何も開始しないでください。これは非常に不便であり、多くの苦痛の問題があります。Tomcat (または Jetty) をアプリケーション内に埋め込み、アプリケーションをプレーンな Java プロセスとして実行するだけです。