Documentation

You are viewing the documentation for Play 1. The documentation for Play 2 is here.

Play 1.2 — リリースノート

Play 1.2 におけるバグフィックスについては ロードマップページ で読むことができます。このページでは重要な変更に注目します。

1.1.x からの移行

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 アプリケーションには三種類の依存性があります:

これらの依存性をアプリケーションの 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 では新しく一貫性のある完全な機能セットを実装しました。

Promises

Play 1.2 には Play のカスタム Future 型である Promise が導入されます。実際のところ、 Promise<T> は Future<T> でもあるので、標準的な Future に対しても使用することができます。しかし、Promise には興味深い追加機能: 期待する値が利用可能になると、できるだけ早く呼び出される onRedeem(…) を使ってコールバックを登録する機能が備わっています。フレームワークが、自身を登録し、利用可能になったらすぐにリクエストを実行するようリスケジュールすることができます。

play.libs.F

Promise 型は、いくつかの便利な関数プログラミング構造を提供する新しいライブラリ (play.libs.F) の一部です。私たちは Java におけるパターンマッチングも必要だと感じました。残念ながら Java は組み込みのパターンマッチングを持ち合わせておらず、関数構造の欠如により、パターンマッチングをライブラリとして追加することも困難でした。とにかく、私たちはそれほど悪くない解決策に取り組みました。

await(…)

アプリケーションコードが Promise<T> を使って、まだ利用可能でない値を返すとき、リクエストを再開する前に、この期待する結果が利用可能になるのを待つよう Play に指示できたらよいと思うでしょう。これは、コードに明記することができます。

“あとで結果が利用可能になるまで待ちます”

そこでフレームワークは以下のように扱います

"了解、コードを中止し、他のリクエストを扱うためにスレッドを再利用します。そして期待する値が利用可能になったら、速やかにコードを再開します"

継続

フレームワークは、別のリクエストを扱うために使用していたスレッドを回収する必要があるので、コードの実行を中断しなければなりません。以前のバージョンの Play の @waitFor(…) と等価である @await(…) は、アクションを中断し、その後、始めから再度呼び出します。

Play 1.2 において非同期処理をより簡単に扱うために、継続を紹介します。継続は等価的にコードを中断し、再開します。

Response ストリーム

リクエストをブロックせずにループすることができるので、結果の一部の準備が整い次第、ブラウザにデータを送りたくなるかもしれません。これは HTTP レスポンスタイプ Content-Type:Chunked のポイントです。このレスポンスタイプでは、複数のチャンクを使って数回の HTTP レスンポンすを送ることができます。ブラウザはチャンクが発行され次第、これを受け取ります。

WebSockets

WebSockets は、ブラウザとアプリケーション間の双方向コミュニケーションチャネルを開く方法です。WebSockets は Play アプリケーションでサポートされるようになりました。

新しいチャットサンプルアプリケーション

これらすべての新機能は、標準的なチャットアプリケーションを三つの異なる方法で達成している Chat サンプルアプリケーションで使用されています:

routes ファイルの改善

routes ファイルは一連の新機能をサポートします。ルートパスの正規表現に { と } の文字を安全に使うこともできます。

staticFile: マッピング

古い staticDir マッピングのように、描画する静的なフィルへの URL パスを直接マッピングすることができます。

# Serve index.html static file for home requests
GET     /home                   staticFile:/public/html/index.html

404 アクション

アプリケーションにおいて無視されなければならない URL パスを印付けるために、 404 をアクションルートとして直接使用することができます。例えば:

# Ignore favicon requests
GET     /favicon.ico            404

WS メソッド

新しい WS メソッドは、WebSocket にマッピングされるルートを定義することができます。

# A WebSocket
WS    /chat/messages            Chat.messages

以下のような URL をリバースして生成するために、 @@{Chat.messages()} のような注記を使うことができます:

ws://localhost:9000/chat/messages

データベースエボリューション

リレーショナルデータベースを使用する場合、データベーススキーマの変更を追跡し、管理する方法が必要になります。Play は自動的にこれらの変更を追跡し、スキーマを更新します。

これは、同じアプリケーションで複数の開発者が作業するときに発生する競合も解決します。

Invocation コンテキストアノテーション

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);
}

この起動コンテキストの概念は、あらゆるプラグインに適用することができます。

デフォルトのインメモリ H2 データベース

Play のインメモリデータベースとして H2 データベース を使用します。H2 データベースは MySQL のような本番用データベースとの互換性が高いので、デプロイにおける問題は少なくなるでしょう。

良い副作用として、H2 は db=mem が設定されているどのような Play アプリケーション でも /@db という URL で起動できる Web コンソールを提供します。

テストランナーの更新

テストランナーに関するいくつかの更新があります。

あらゆる JUnit テストランナーにおける JUnit テストの実行

Eclipse が提供するような、あらゆる既存の JUnit テストランナーにおいて Java テストケースを直接実行することができます。

Surefire レポート

どのような Java テストクラスでも、テストを実行すると CI ソフトウェアと容易に統合できる Surefire レポートが生成されます。

YAML フィクスチャ

複数の YAML ファイルから一度にフィクスチャをロードできますし、ある種の動的なデータを追加するために YAML 定義にテンプレートエンジンマークアップ言語を使用することもできます。

複数のテスト ID

test-* にマッチするフレームワーク ID を指定することで、ひとつ以上のテスト環境を作成することができます。

チートシートの提供

Play のドキュメントに、一般的な Play の関数を素早く参照するためのいくつかのチートシートを含めました。このチートシートは簡単に印刷できます。

その他の小さな機能

130 のバグフィックス に加えて、以下の小さな新機能が含まれます。