Play フレームワークはサーブレット仕様をサポートしていませんが、デプロイ オプションの中には、アプリ全体を war ファイルにパッケージ化し、任意のサーブレット コンテナーにデプロイする可能性があります。
バージョン 1.1 から、play は統合 Web サーバーとしてnettyを使用します。
play アプリが war ファイルにデプロイされるとどうなるのだろうと思っていました。
まだサーブレットコンテナ内で netty を使用してラップしていますか? 顕著なパフォーマンス コストはありますか? それとも単にサーブレット コンテナにアクセスするのでしょうか。
Niels が言うように、Play は他のプラットフォームへのデプロイに Netty を使用しません。
play runまたはコマンドを使用して Play を実行するplay startと、Netty を使用してリクエストが管理され、Play フレームワークに渡されます。
ただし、別のアプリケーション サーバーにデプロイする場合、これは不可能です。そのため、Play は HTTP 処理を ServletWrapper にラップします。これにより、Play の通常の動作が効果的に変換され、Servlet 仕様に準拠した J2EE スタックで使用できるようになります。
このラッパーの特定のコードは、ここにあります。WAR ファイルをビルドすると、Play はこの ServletWrapper を公開されたサーブレットとして効果的に配置し (Struts が ActionServlet で行うのと同じように)、リクエストを適切な場所にルーティングするために必要な作業を処理します。
私の知る限り、netty は使用していません。作業をプレイクラスに委譲する特別なサーブレットがあります。Glassfish だけがネイティブの play-container を持っています。パフォーマンスに明らかに悪影響を及ぼします。
このページが示唆するように、
Play 1.2 では、コマンドを使用して.warファイルを取得しplay war myapp -o myapp.war、そのページにリストされている Java EE サーバーの 1 つにデプロイできます。