§Play 2.2 移行ガイド

これは Play 2.1 から Play 2.2 への移行ガイドです。Play の以前のバージョンから移行する必要がある場合は、まず Play 2.1 移行ガイドに従う必要があります。

§ビルドタスク

§Play の組織 ID とバージョンの更新

Play は、別の組織 ID で公開されるようになりました。これは、最終的に Play を Maven Central にデプロイできるようにするためです。古い組織 ID は play で、新しい組織 ID は com.typesafe.play です。

バージョンも 2.2.0 に更新する必要があります。

project/plugins.sbt で、新しい組織 ID を使用するように Play プラグインを更新します。

addSbtPlugin("com.typesafe.play" % "sbt-plugin" % "2.2.0")

さらに、Play アーティファクトに依存する他の依存関係があり、ヘルパーを使用してそれらに依存していない場合は、そこで組織 ID とバージョン番号を更新する必要がある場合があります。

§sbt バージョンの更新

sbt 0.13.0 を使用するように project/build.properties を更新する必要があります。

§ルートプロジェクトの更新

マルチプロジェクトビルドを使用していて、プロジェクトのいずれにも現在のディレクトリのルートディレクトリがない場合、ルートプロジェクトはアルファベット順ではなく、rootProject をオーバーライドすることで決定されるようになりました。

override def rootProject = Some(myProject)

§Scala バージョンの更新

(例: マルチプロジェクトビルドで `play.Project`に加えて `Project` を使用しているため) `scalaVersion` を設定している場合は、それを 2.10.2 に更新する必要があります。

§Play キャッシュモジュール

Play キャッシュは、独自のモジュールに分割されるようになりました。Play キャッシュを使用している場合は、これを依存関係として追加する必要があります。たとえば、Build.scala では次のようになります。

val addDependencies = Seq(
  jdbc,
  cache,
  ...
)

2.2 より前のバージョンの Play に依存するプラグインに依存している場合、複数のキャッシュがロードされるため、キャッシング内で競合が発生します。この問題が発生した場合は、新しいプラグインバージョンに更新するか、古い Play バージョンを除外してください。

§sbt 名前空間は拡張されなくなりました

sbt 名前空間は以前は Play によって拡張されていました (例: sbt.PlayCommands.intellijCommandSettings)。これは悪い習慣とみなされているため、
Play は、sbt 関連のものに独自のネームスペースを使用するようになりました (例: play.PlayProject.intellijCommandSettings)。

§Scala の新しい結果構造

アクションの合成とフィルタリングを簡素化するために、Play の結果構造が簡素化されました。以前は SimpleResult、ChunkedResult、AsyncResult、およびインターフェース Result と PlainResult がありましたが、現在は 1 つのタイプの結果 SimpleResult だけになりました。SimpleResult を除くすべてが非推奨となりました。SimpleResult のサブクラスである Status は、結果を構築するための便利なクラスとして引き続き存在します。ほとんどの場合、アクションは非推奨のタイプを使用できますが、非推奨の警告が表示されます。ただし、合成とフィルターを実行するアクションは、SimpleResult を使用する必要があります。

§非同期アクション

以前は、次のコードを使用していた可能性があります。

def asyncAction = Action {
  Async {
    Future(someExpensiveComputation)
  }
}

Action.async ビルダーを使用できるようになりました。

def asyncAction = Action.async {
  Future(someExpensiveComputation)
}

§チャンク結果の処理

以前は、Status の stream メソッドを使用してチャンク結果を作成していました。これは非推奨となり、結果がチャンクされることが明確になる chunked メソッドに置き換えられました。例:

def cometAction = Action {
  Ok.chunked(Enumerator("a", "b", "c") &> Comet(callback = "parent.cometMessage"))
}

ChunkedResult を直接作成または使用した高度な用途は、TransferEncoding: chunked ヘッダーを手動で設定/確認し、新しい Results.chunk および Results.dechunk enumeratee を使用するコードに置き換える必要があります。

§アクションの合成

アクションの合成には、アクションを構築するための ActionBuilder 実装を使用することをお勧めします。

これらを実行する方法の詳細については、こちらを参照してください。

§フィルター

EssentialAction によって生成される iteratee は、Result ではなく SimpleResult を生成するようになりました。つまり、結果を処理する必要があったフィルターは、AsyncResult を PlainResult にアンラップする必要がなくなったため、すべてのフィルターがはるかにシンプルで書きやすくなりました。以前アンラップを実行していたコードは、一般的に単一の iteratee map コールに置き換えることができます。

§play.api.http.Writeable アプリケーション

以前は、SimpleResult のコンストラクターは、渡された Enumerator の型に対して Writeable を受け取っていました。現在は、その enumerator は Array[Byte] である必要があり、Writeable は Status の便利なメソッドに対してのみ使用されます。

§テスト

以前は、Helpers.route() および同様のメソッドは Result を返し、常に AsyncResult になり、Helpers の他のメソッド (例: status、header、contentAsString) は Result をパラメーターとして受け取っていました。現在は、Future[SimpleResult] が Helpers.route() によって返され、抽出メソッドによって受け入れられます。型推論を使用して型を決定する多くの一般的なユースケースでは、テストコードに変更を加える必要はありません。

§Java の新しい結果構造

アクションの合成を簡素化するために、Java の結果構造が変更されました。AsyncResult は非推奨となり、SimpleResult が導入され、通常の結果と AsyncResult タイプが区別されるようになりました。

§非同期アクション

以前は、非同期アクションの future は async 呼び出しでラップする必要がありました。現在は、アクションは Result または Promise<Result> のいずれかを返すことができます。例:

public static Promise<Result> myAsyncAction() {
  Promise<Integer> promiseOfInt = Promise.promise(
    new Function0<Integer>() {
      public Integer apply() {
        return intensiveComputation();
      }
    }
  );
  return promiseOfInt.map(
    new Function<Integer, Result>() {
      public Result apply(Integer i) {
        return ok("Got result: " + i);
      }
    }
  );
}

§アクションの合成

play.mvc.Action の call メソッドのシグネチャは、Promise<SimpleResult> を返すように変更されました。結果を処理していない場合は、通常、必要な変更は型シグネチャの更新だけです。

§Iteratee の実行コンテキスト

アプリケーションで提供されたコードを実行する iteratee、enumeratee、および enumerator は、暗黙的な実行コンテキストを必要とするようになりました。例:

import play.api.libs.concurrent.Execution.Implicits._

Iteratee.foreach[String] { msg =>
  println(msg)
}

§同時 F.Promise 実行

Play 2.2 では、F.Promise クラスがユーザー提供のコードを実行する方法が変更されました。

Play 2.1 では、F.Promise クラスはユーザーコードの実行方法を制限していました。特定の HTTP リクエストの Promise 操作は、送信された順序で実行され、基本的に順番に実行されます。

Play 2.2 では、この順序に関する制限が削除され、Promise 操作を同時に実行できるようになりました。F.Promise クラスによって実行される作業は、実行に他の制限を課すことなく、Play のデフォルトのスレッドプールを使用するようになりました。

ただし、それでも必要とする人のために、Play 2.1 の従来の動作は OrderedExecutionContext クラスにキャプチャされました。Play 2.1 の従来の動作は、F.Promise のメソッドのいずれかに OrderedExecutionContext を引数として指定することで簡単に再現できます。

以下のコードは、Play 2.2でPlay 2.1の動作を再現する方法を示しています。この例では、PlayのデフォルトのActorSystem内で動作する64個のアクターのプールという、Play 2.1と同じ設定を使用していることに注意してください。

import play.core.j.OrderedExecutionContext;
import play.libs.Akka;
import play.libs.F.*;
import scala.concurrent.ExecutionContext;

ExecutionContext orderedExecutionContext = new OrderedExecutionContext(Akka.system(), 64);
Promise<Double> pi = Promise.promise(new Function0<Double>() {
  Double apply() {
    return Math.PI;
  }
}, orderedExecutionContext);
Promise<Double> mappedPi = pi.map(new Function<Double, Double>() {
  Double apply(x Double) {
    return 2 * x;
  }
}, orderedExecutionContext);

§Jackson Json

Jacksonをバージョン2にアップグレードしました。そのため、パッケージ名はorg.codehaus.jacksonではなくcom.fasterxml.jackson.coreになりました。

§配布物の準備

stageタスクとdistタスクは、Native Packager Pluginを使用するようにPlay 2.2で完全に書き直されました。

Playの配布物は、プロジェクトのdistフォルダにはもう作成されません。代わりに、プロジェクトのtargetフォルダに作成されます。

もう1つの変更点は、Playアプリケーションを起動するUnixスクリプトの場所です。2.2以前は、Unixスクリプトはstartという名前で、配布物のルートレベルフォルダにありました。2.2では、startスクリプトはプロジェクト名と同じ名前になり、配布物のbinフォルダに配置されます。さらに、WindowsでPlayアプリケーションを起動できる.batスクリプトが用意されています。

startスクリプトに渡される引数の形式が変更されたことに注意してください。現在受け入れられている引数を確認するには、startスクリプトで-hを実行してください。

新しいstageタスクとdistタスクの詳細については、「本番モードでのアプリケーションの起動」のドキュメントを参照してください。

§Akka 2.1から2.2へのアップグレード

Akka 2.1から2.2へのアップグレードに関する移行ガイドは、こちらにあります。

次へ: Play 2.1

このドキュメントに誤りを見つけましたか？このページのソースコードはこちらにあります。ドキュメントガイドラインを読んだ後、プルリクエストを送信してください。ご質問やアドバイスがありましたら、コミュニティフォーラムでコミュニティと会話してください。