Play 1.2 におけるバグフィックスについては ロードマップページ で読むことができます。このページでは重要な変更に注目します。
Play 1.1.x からの以降は実に簡単です。アプリケーションのレイアウトはまったく変わらないので、あなたのアプリケーションは Play 1.2 で動作するでしょう。しかし、アプリケーションにおいて外部のモジュールを使用している場合、Play 1.2 と互換性のある、より新しいバージョンを使用しなければならないかもしれません。対応するモジュールのページをチェックしてください。
長い間、非推奨とした後に Play 1.2 においていくつかの API を削除しましたが、ほとんどの public な API は変わりありません。どのようにして解決したらよいか分からないコンパイルエラーがあったら Google グループ で質問してください。
FunctionalTest
からコントローラを呼び出すと、このアクションは独自のトランザクション配下で実行されるようになりました。テスト自身も独自のトランザクションで実行されるため、デッドロックが発生する可能性があります。このため、テストの実行中はデータベースを READ_UNCOMMITED に設定した方がよいです。インメモリの H2 データベースでテストをくり返すのであれば、以下のデータベース設定を使用してください:
%test.db.url=jdbc:h2:mem:play;MODE=MYSQL;LOCK_MODE=0@
データベースに READ_UNCOMMITED を設定できない場合は、(JPA.em().getTransaction()
を使って) 手動で JPA トランザクションを管理するか、 ジョブ を使って起動することで、すべての JPA アクセスをそれぞれ独自のトランザクションで実行する必要があります。
Play の依存性管理システム によって、アプリケーションの外部依存性を単一の dependencies.yml
ファイルに記述することができます。
Play アプリケーションには三種類の依存性があります:
lib/
ディレクトリにインストールされた JAR ファイルとして提供されるあらゆる Java ライブラリmodules/
ディレクトリにインストールされた (実際はアプリケーションの断片である) Play モジュールこれらの依存性をアプリケーションの conf/dependencies.yml
ファイルに記述すると、Play はすべての必要な依存性を解決し、ダウンロードしてインストールします。
例えば、このファイルは以下のように使います:
# Application dependencies
require:
- play
- com.google.guava -> guava r07
- play -> pdf 0.2
`play dependencies`
を実行することができます:
この依存性管理は、内部では Apache Ivy を利用しており、Maven 互換のリポジトリをサポートします。
Play 1.1 から既に Java Future と、 waitFor(…)
と suspend(…)
のコントローラメソッドを使って非同期処理を達成していました。しかし、これら初期のものは決して使い易くありませんでした。そこで Play 1.2 では新しく一貫性のある完全な機能セットを実装しました。
Play 1.2 には Play のカスタム Future 型である Promise が導入されます。実際のところ、 Promise<T>
は Future<T>
でもあるので、標準的な Future に対しても使用することができます。しかし、Promise には興味深い追加機能: 期待する値が利用可能になると、できるだけ早く呼び出される onRedeem(…)
を使ってコールバックを登録する機能が備わっています。フレームワークが、自身を登録し、利用可能になったらすぐにリクエストを実行するようリスケジュールすることができます。
Promise 型は、いくつかの便利な関数プログラミング構造を提供する新しいライブラリ (play.libs.F) の一部です。私たちは Java におけるパターンマッチングも必要だと感じました。残念ながら Java は組み込みのパターンマッチングを持ち合わせておらず、関数構造の欠如により、パターンマッチングをライブラリとして追加することも困難でした。とにかく、私たちはそれほど悪くない解決策に取り組みました。
アプリケーションコードが Promise<T>
を使って、まだ利用可能でない値を返すとき、リクエストを再開する前に、この期待する結果が利用可能になるのを待つよう Play に指示できたらよいと思うでしょう。これは、コードに明記することができます。
“あとで結果が利用可能になるまで待ちます”
そこでフレームワークは以下のように扱います
"了解、コードを中止し、他のリクエストを扱うためにスレッドを再利用します。そして期待する値が利用可能になったら、速やかにコードを再開します"
フレームワークは、別のリクエストを扱うために使用していたスレッドを回収する必要があるので、コードの実行を中断しなければなりません。以前のバージョンの Play の @waitFor(…) と等価である @await(…) は、アクションを中断し、その後、始めから再度呼び出します。
Play 1.2 において非同期処理をより簡単に扱うために、継続を紹介します。継続は等価的にコードを中断し、再開します。
リクエストをブロックせずにループすることができるので、結果の一部の準備が整い次第、ブラウザにデータを送りたくなるかもしれません。これは HTTP レスポンスタイプ Content-Type:Chunked
のポイントです。このレスポンスタイプでは、複数のチャンクを使って数回の HTTP レスンポンすを送ることができます。ブラウザはチャンクが発行され次第、これを受け取ります。
WebSockets は、ブラウザとアプリケーション間の双方向コミュニケーションチャネルを開く方法です。WebSockets は Play アプリケーションでサポートされるようになりました。
これらすべての新機能は、標準的なチャットアプリケーションを三つの異なる方法で達成している Chat サンプルアプリケーションで使用されています:
routes
ファイルは一連の新機能をサポートします。ルートパスの正規表現に { と } の文字を安全に使うこともできます。
古い staticDir
マッピングのように、描画する静的なフィルへの URL パスを直接マッピングすることができます。
# Serve index.html static file for home requests
GET /home staticFile:/public/html/index.html
アプリケーションにおいて無視されなければならない URL パスを印付けるために、 404
をアクションルートとして直接使用することができます。例えば:
# Ignore favicon requests
GET /favicon.ico 404
新しい WS
メソッドは、WebSocket にマッピングされるルートを定義することができます。
# A WebSocket
WS /chat/messages Chat.messages
以下のような URL をリバースして生成するために、 @@{Chat.messages()}
のような注記を使うことができます:
ws://localhost:9000/chat/messages
リレーショナルデータベースを使用する場合、データベーススキーマの変更を追跡し、管理する方法が必要になります。Play は自動的にこれらの変更を追跡し、スキーマを更新します。
これは、同じアプリケーションで複数の開発者が作業するときに発生する競合も解決します。
Play は (例えば HTTP リクエスト、WebSocket メッセージ、または非同期ジョブの実行などの) 起動を、それぞれ Invocation としてマッピングします。あらゆる起動は、ある特定の起動を扱い方を変更するためにプラグインから使用されるアノテーションによって、注釈することができます。
例えば、 JPA Plugin はデータベースが設定されている場合、それぞれの呼び出しについて自動的にデータベーストランザクションを開始します。特定の呼び出しにはデータベース接続が必要ない場合、 @NoTransaction
で註釈することができます:
@NoTransaction
public static void index() {
render();
}
別のアノテーションでは、特定の呼び出しに読み出し専用のトランザクションを指定することができます;
@Transactional(readOnly=true)
public static show(Long id) {
Post post = Post.findById(id);
render(post);
}
この起動コンテキストの概念は、あらゆるプラグインに適用することができます。
Play のインメモリデータベースとして H2 データベース を使用します。H2 データベースは MySQL のような本番用データベースとの互換性が高いので、デプロイにおける問題は少なくなるでしょう。
良い副作用として、H2 は db=mem が設定されているどのような Play アプリケーション でも /@db という URL で起動できる Web コンソールを提供します。
テストランナーに関するいくつかの更新があります。
Eclipse が提供するような、あらゆる既存の JUnit テストランナーにおいて Java テストケースを直接実行することができます。
どのような Java テストクラスでも、テストを実行すると CI ソフトウェアと容易に統合できる Surefire レポートが生成されます。
複数の YAML ファイルから一度にフィクスチャをロードできますし、ある種の動的なデータを追加するために YAML 定義にテンプレートエンジンマークアップ言語を使用することもできます。
test-*
にマッチするフレームワーク ID を指定することで、ひとつ以上のテスト環境を作成することができます。
Play のドキュメントに、一般的な Play の関数を素早く参照するためのいくつかのチートシートを含めました。このチートシートは簡単に印刷できます。
130 のバグフィックス に加えて、以下の小さな新機能が含まれます。
create()
と validateAndCreate()
メソッドplay
コマンドへの --pid_file=
, --http.port=
, --https.port=
コマンドラインオプションの追加Map<String, String>
へのバインディングObjectType
を作成する機能