PlayFramework は、再起動や再デプロイを行わずに実行時にコードの変更を表示するにはどうすればよいですか? 内部でTomcatを使用していますか？そうでない場合は、Spring アプリを、それが使用するサーバー コンテナーの上に配置して、ランタイムの変更の利点を得ることができますか。
注: Tomcat でも技術的には可能であることはわかっていますが、私が経験したところによると、非常にバグが多く、常に機能するとは限りません。場合によっては、アプリケーション コンテキスト全体 (約 16 秒) をリロードする必要さえありますが、これは的外れです。
Zenklysが指摘しているように、Playは、Javaファイルの最終変更日をチェックし、実行時に生成される.classファイルと相互参照することで機能します。何かが変更されたことを認識すると、実行時にそれらを再コンパイルします。
Play 1.xでは、再コンパイルはeclipse jdtコンパイラー（org.eclipse.jdt.internal.compiler.Compiler）を使用して行われます。Play 1.xのコードを確認したい場合は、次のクラスをご覧ください-https://github.com/playframework/play/blob/master/framework/src/play/classloading/ApplicationCompiler.java
Play 2.xでは、PlayがSBTツールと相互リンクすることでそれを行っているように見えます。これをチェックしてください-https://github.com/playframework/Play20/blob/master/framework/src/play/src/main/scala/play/core/system/ApplicationProvider.scala
まず第一に、これは開発モードで実行している場合にのみ当てはまります。prod モードでは、変更は検出されなくなりました。
私が理解している限り、それはアプリケーションが .class ファイルからではなく .java ファイルから実行されているためです。これらのファイルの最終更新日を観察することで、Play はいつアプリケーションを再コンパイルするかを検出できます。
JRebelのようなものを探しています。
遊ぶ！Tomcat やその他のサーブレット コンテナーは使用しません。Netty の上で実行されるため、実際には Java EE 仕様には準拠していません。ただし、アプリを war パッケージにアセンブルして、Jetty/Tomcat/you-name-it-server にデプロイすることはできます。
間違っているかもしれませんが、Play! おそらく、新しいクラス定義をロードするために使い捨てのクラスローダーを使用します。これが、再ロードメカニズムが通常のホットスワップよりも優れている理由です。
JBossを使用してEclipse内で実行している場合は、JBossデプロイディレクトリをローカルプロジェクトにポイントできます。インジェクションやメソッドシグネチャを変更しない限り、コードを変更することができ、それらは約75％の確率で認識されます。JBossはサーブレットコンテナとしてTomcatを使用するため、Tomcatも同じように設定できます。
Jrebelもこの目的のために特別に作られています。