§Play 2.4 移行ガイド

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

このページに記載されている情報だけでなく、いくつかのトピックに関するより詳細な移行情報があります。

§Java 8 サポート

Java 6とJava 7のサポートは廃止され、Play 2.4にはJava 8が必要です。この決定は、Java 7が2015年4月にサポート終了になったという事実に基づいて行われました。また、Java 8はクリーンなAPIを可能にし、関数型プログラミングスタイルをよりよくサポートします。Java 6/7でPlay 2.4を使用しようとすると、以下のようなエラーが発生します。

java.lang.UnsupportedClassVersionError: play/runsupport/classloader/ApplicationClassLoaderProvider : Unsupported major.minor version 52.0

java.lang.UnsupportedClassVersionErrorは、コンパイルされたクラスファイルよりも古いバージョンのJavaでJavaクラスファイルを読み取ることがサポートされていないことを意味します。

注： Scala 2.10は、インターフェイスの静的メソッドなど、すべてのJava 8言語機能を完全にサポートしているわけではありません。プロジェクトにJava 8で導入されたこれらの新機能を使用するJavaコードがある場合は、Scala 2.11.6以降を使用するようにアップグレードしてください。プロジェクトでscalaVersionを設定する方法については、sbtドキュメントを参照してください。

§ビルドの変更

sbtでPlayプロジェクトをロード/実行する前に、sbtビルドを更新するために次の手順を実行する必要があります。

§Playのアップグレード

Playをアップグレードするには、project/plugins.sbtのPlayバージョン番号を更新します。

addSbtPlugin("com.typesafe.play" % "sbt-plugin" % "2.4.0") // Set to latest version of Play 2.4

§sbtのアップグレード

Play 2.4では、sbt 0.13.8以上が必要です。project/build.propertiesを次のように更新します。

sbt.version=0.13.8

§別のモジュールでのSpecs2サポート

以前にPlayのspecs2サポートを使用していた場合は、プロジェクトに明示的に依存関係を追加する必要があります。

libraryDependencies += specs2 % Test

.scalaビルドファイルを使用している場合は、次のインポートを追加する必要があります：import play.sbt.PlayImport._

§別のモジュールでのデータベースエボリューションのサポート

データベースエボリューションのサポートは、以前はPlay JDBCとJPAサポートの両方に含まれていました。そうではなくなりました。したがって、エボリューションを使用している場合は、プロジェクトのビルドでevolutionsへの明示的な依存関係を追加する必要があります。

libraryDependencies += evolutions

一方、エボリューションを使用していない場合は、application.confからevolutionplugin=disabledを安全に削除できるようになりました。

構成キーが変更されたため、evolutionplugin=disabledの代わりに、play.evolutions.enabled=falseを使用する必要があります（エボリューションの構成を参照）。

Play Slickモジュール（エボリューションの有無にかかわらず）を使用している場合は、状況が大幅に変わったため、Play Slick移行ガイドを必ずお読みください。

§IDE：EclipseとIntelliJ IDEA

Playには、sbteclipseまたはsbt-ideaプラグインは含まれておらず、これによりユーザーはPlayとは独立してIDEサポートをアップグレードできます。

Eclipseサポートは、プラグインをインポートするための1行の追加で設定できます。詳細については、ドキュメントを参照してください。

IntelliJはsbtプロジェクトをネイティブにインポートできるようになったため、代わりにそれを使用することをお勧めします。または、sbt-ideaプラグインを手動でインストールして使用することもできます。手順はこちらにあります。

§Play sbtプラグインAPI

sbtプラグインのすべてのクラスは、play.sbtパッケージに含まれるようになりました。これは、.scalaファイルを使用してビルドを構成する場合に特に重要です。playが提供する構成要素を使用するには、play.sbt.PlayImportから識別子をインポートする必要があります。

§`playWatchService`の名前変更

sbt設定キーplayWatchServiceはfileWatchServiceに名前が変更されました。

また、対応するクラスも変更されました。FileWatchServiceを2秒ごとにポーリングするように設定するには、次のように使用します。

PlayKeys.fileWatchService := play.runsupport.FileWatchService.sbt(2000)

§Play Slickの依存関係

Play Slickモジュールは、Slick 3.0をサポートするために大幅なリスタイルを行いました。スムーズなアップグレードのために、Play Slick移行ガイドをお読みください。

§Ebeanの依存関係

Ebeanは、Play自身のライフサイクルとは独立したライフサイクルを持つことができるように、外部プロジェクトに引き出されました。Ebeanバイトコード拡張機能も、Play sbtプラグインから独自のプラグインに抽出されました。

Ebeanを使用する既存のPlayプロジェクトを新しい外部Ebeanプラグインを使用するように移行するには、build.sbtのlibraryDependenciesからjavaEbeanを削除し、project/plugins.sbtに以下を追加します。

addSbtPlugin("com.typesafe.sbt" % "sbt-play-ebean" % "1.0.0")

その後、プロジェクトのEbeanプラグインを有効にします。

lazy val myProject = (project in file("."))
  .enablePlugins(PlayJava, PlayEbean)

そして最後に、Ebeanマッピングクラスをカンマ区切りの文字列ではなくリストとして構成します（これはまだサポートされていますが、非推奨になりました）。

ebean.default = ["models.*"]
ebean.orders = ["models.Order", "models.OrderItem"]

さらに、Ebeanは4.5.xにアップグレードされ、以前にPlay自体が追加したModelクラスを含むいくつかの機能が取り込まれています。したがって、PlayのModelクラスは非推奨になり、com.avaje.ebean.Modelを使用することが推奨されます。

§バイトコード拡張

Javaプロパティのゲッターとセッターを生成するPlayのバイトコード拡張は、Playのコアから、独自のライフサイクルを持つことができる個別の管理プロジェクトに引き出されました。有効にするには、project/plugins.sbtファイルに以下を追加します。

addSbtPlugin("com.typesafe.sbt" % "sbt-play-enhancer" % "1.1.0")

§依存性注入

Playは現在、デフォルトでGuiceによって提供される依存性注入を使用しています。これは、Playからグローバルステートを削除する長期的な戦略の一部であり、Play 3.0リリースで完了することを願っています。アプリケーションをグローバルステートに依存することから、完全にグローバルステートフリーに移行することは、大きなタスクであり、一度にすべてを行うと非常に混乱する可能性があります。このため、Playで採用したアプローチは、変更を複数のリリースに分散し、エンドユーザーがコードを徐々に移行してグローバルステートに依存しないようにすることです。一度にすべてを強制するのではなく。

可能な限り、Play 2.4で提供されるAPIがPlay 2.3とソース互換性があることを保証しました。これは、多くの場合、グローバルステートに依存する方法と依存しない方法の2つの方法があることを意味します。ドキュメントを更新して、新しい依存性注入のアプローチを反映しました。古いAPIを引き続き使用し、それらに関するドキュメントを参照する場合は、一般的に、Play 2.3ドキュメントがまだ関連しています。

Play 2.4への移行を進める前に、Playでの依存性注入に関するドキュメントを読むことが重要です。事前にいくつかの決定を下す必要があります。デフォルトでは、依存性注入にGuiceの使用を提供および推奨しますが、Scalaでのコンパイル時依存性注入技術を含む、他の多くの依存性注入ツールと技術も可能です。依存性注入については、JavaまたはScalaで読むことができます。

§ルーティング

依存性注入に関する最も大きな混乱の1つは、2つのスタイルのルーターの生成をサポートするようになったことです。1つ目は既存の静的スタイルであり、これはPlay 2.3ルーターからほとんど変更されていません。これはScalaシングルトンオブジェクトであり、呼び出すすべてのアクションがScalaシングルトンオブジェクトまたはJava静的メソッドであると想定します。2つ目は、コンストラクターで依存関係を宣言するクラスである依存性注入ルーターです。これら2つのルーターの違いを示すために、次のルートファイルを考えてみましょう。

GET   /               controllers.Application.index
POST  /save           controllers.Application.save
GET   /assets/*file   controllers.Assets.versioned(path = "/public", file: Asset)

静的ルートジェネレーターは、非常に大まかに（疑似コード）次のようなルーターを生成します。

object Routes extends GeneratedRouter {
  def routes = {
    case ("GET", "/") => controllers.Application.index
    case ("POST", "/save") => controllers.Application.save
    case ("GET", "/assets/:file") => controllers.Assets.versioned("/public", file)
  }
}

一方、注入されたルートジェネレーターは、非常に大まかに次のようなルーターを生成します。

class Routes(application: controllers.Application, assets: controllers.Assets) extends GeneratedRouter {
  def routes = {
    case ("GET", "/") => application.index
    case ("POST", "/save") => application.save
    case ("GET", "/assets/:file") => assets.versioned("/public", file)
  }
}

デフォルトでは、静的ルートジェネレーターが使用されます。Javaアクションをすべて非静的メソッドに、またはScalaアクションをクラスに移行する準備ができていない場合は、これを使用する必要があります。ほとんどの場合、これは非常に簡単に行えます。Javaではstaticキーワードを削除する必要があり、Scalaではobjectという単語をclassに変更する必要があります。静的ルーターは、ランタイムInjectorからアクションを検索するように指示する@演算子もサポートしています。アクションの一部が静的で一部がインジェクトされている移行期間中には、これが役立つ場合があります。

インジェクトされたジェネレーターに切り替えたい場合は、build.sbtのビルド設定に以下を追加してください。

routesGenerator := InjectedRoutesGenerator

デフォルトでは、PlayはGuiceを使用してこのルーターの配線を自動的に処理しますが、採用しているDIアプローチによっては、カスタマイズできる場合があります。

インジェクトされたルートジェネレーターも、ルートで@演算子をサポートしていますが、（すべてがインジェクトされるため）意味が少し異なります。コントローラーに@をプレフィックスとして付けると、そのコントローラーが直接インジェクトされるのではなく、そのコントローラーのJSR 330 Providerがインジェクトされます。これは、例えば、循環依存の問題を解消したり、リクエストごとに新しいアクションをインスタンス化する場合に使用できます。

さらに、Playはデフォルトで、ルートパッケージではなく、routerパッケージにルーターを生成するようになりました。これは依存性注入を支援するためです。必要に応じて、手動で作成またはバインドできます。ルートパッケージのクラスは通常、参照できないためです。

§依存性注入されたコンポーネント

Play 2.4では、依存性注入されたバージョンのコンポーネントの使用を強制することはありませんが、それらへの切り替えを開始することを推奨します。次の表は、グローバルな状態を使用する古い静的APIと、切り替える必要がある新しいインジェクトされたAPIを示しています。

§Scala

旧API	新API	コメント
`Lang`	`Langs`
`Messages`	`MessagesApi`	`preferred`メソッドのいずれかを使用すると、`Messages`インスタンスを取得できます。
`DB`	`DBApi`または、より良い`Database`	`@NamedDatabase`アノテーションを使用すると、特定のデータベースを取得できます。
`Cache`	`CacheApi`または、より良い	`@NamedCache`アノテーションを使用すると、特定のキャッシュを取得できます。
`Cached`オブジェクト	`Cached`インスタンス	コンパニオンオブジェクトの代わりに、インジェクトされたインスタンスを使用します。`@NamedCache`アノテーションを使用できます。
`Akka`	N/A	もはや必要ありません。`ActorSystem`への依存関係を宣言するだけです。
`WS`	`WSClient`
`Crypto`	`Crypto`
`GlobalSettings`	`HttpErrorHandler`、`HttpRequestHandler`、および`HttpFilters`	以下のGlobalSettingsセクションの詳細をお読みください。

§Java

旧API	新API	コメント
`Lang`	`Langs`	`Lang`オブジェクトのインスタンスは引き続き使用できます。
`Messages`	`MessagesApi`	`preferred`メソッドのいずれかを使用すると、`Messages`インスタンスを取得でき、その後、`at`を使用して、その言語のメッセージを取得できます。
`DB`	`DBApi`または、より良い`Database`	`@NamedDatabase`アノテーションを使用すると、特定のデータベースを取得できます。
`JPA`	`JPAApi`
`Cache`	`CacheApi`	`@NamedCache`アノテーションを使用すると、特定のキャッシュを取得できます。
`Akka`	N/A	もはや必要ありません。`ActorSystem`への依存関係を宣言するだけです。
`WS`	`WSClient`
`Crypto`	`Crypto`	古い静的メソッドは削除されました。`play.Play.application().injector().instanceOf(Crypto.class)`を使用して、インスタンスに静的にアクセスできます。
`GlobalSettings`	`HttpErrorHandler`、`HttpRequestHandler`、および`HttpFilters`	以下のGlobalSettingsセクションの詳細をお読みください。

§GlobalSettings

依存性注入を使用したい場合は、GlobalSettings実装クラスからできるだけ多くのコードを移動することをお勧めします。詳細については、`GlobalSettings`移行ドキュメントをお読みください。

§`Plugin`の非推奨

Javaのplay.Plugin型とScalaのplay.api.Plugin型の両方が非推奨になりました。PluginからModuleへの移行を読んで、コードをplay.api.inject.Moduleを使用するように更新してください。

§構成の変更

Play 2.4では、すべてのプロパティのドキュメントとデフォルトを指定するためにreference.confを使用するようになりました。これは、ここにアクセスして、reference.confという名前のファイルを検索することで簡単に見つけることができます。

さらに、Playは、多数の構成プロパティの名前空間を改善しました。古い構成パスは通常は引き続き機能しますが、それらを使用すると、実行時に非推奨の警告が出力されます。変更されたキーの概要を以下に示します。

古いキー	新しいキー
`application.secret`	`play.crypto.secret`
`application.context`	`play.http.context`
`session.*`	`play.http.session.*`
`flash.*`	`play.http.flash.*`
`application.router`	`play.http.router`
`application.langs`	`play.i18n.langs`
`application.lang.cookie`	`play.i18n.langCookieName`
`parsers.text.maxLength`	`play.http.parser.maxMemoryBuffer`
`csrf`	`play.filters.csrf`
`evolutions.*`	`play.evolutions.*`
`applyEvolutions.<db>`	`play.evolutions.db.<db>.autoApply`
`ws`	`play.ws`

§Akka構成

Play 2.4には、アクタシステムが1つだけになりました。以前は、内部のアクタシステムはplay.akkaで構成され、Akkaプラグインはakkaで構成されていました。新しい結合されたアクタシステムはakkaで構成されています。play.akkaには、アクタシステムの構成はもうありません。ただし、いくつかのPlay固有の設定は、play.akkaプレフィックスの下で引き続き指定されます。

アクタシステムの構成方法を変更したい場合は、play.akka.config = "my-akka"を設定できます。ここで、my-akkaは選択した構成プレフィックスです。

詳細については、JavaまたはScalaのAkkaページを参照してください。

§スレッドプール構成

以前は、2つのアクタシステムでスレッドプール構成が少し異なっていました。アクタシステムが1つになったので、構成がマージされました。また、ほとんどのPlayアプリケーションでパフォーマンスを向上させるLIFO（スタックベース）スケジューリングルールを追加しました。

次の設定は、Play 2.4の新しいデフォルトです。それらはテストで優れたパフォーマンスを発揮することが示されていますが、アプリケーションごとに異なるため、調整するか、Play 2.3の設定に戻す必要がある場合があります。これは、application.confでこれらの値のいずれかをオーバーライドすることで実行できます。以下は新しい設定です。

akka {
  actor {
    default-dispatcher {
      fork-join-executor {
        parallelism-factor = 1.0
        parallelism-max = 24
        task-peeking-mode = LIFO
      }
    }
  }
}

特に、デフォルトのAkka設定を試してみることをお勧めします。

akka {
  actor {
    default-dispatcher {
      fork-join-executor {
        parallelism-factor = 3.0
        parallelism-max = 64
        task-peeking-mode = FIFO
      }
    }
  }
}

詳細については、スレッドプール構成セクションを参照してください。

§HttpRequestHandler

Playがデフォルトで使用するHttpRequestHandlerは、従来のGlobalSettingsメソッドに委譲します。アプリケーションでGlobalSettingsを使用していない場合は、ハンドラーを変更することでパフォーマンスを少し向上させることができます。これを行うには、設定に以下を追加します。

play.http.requestHandler = "play.http.DefaultHttpRequestHandler"

§ロギング

ロギングは、logback構成ファイルのみを介して構成されるようになりました。

§JDBC接続プール

デフォルトのJDBC接続プールは、BoneCPではなく、HikariCPによって提供されるようになりました。

Play接続プールで使用できる構成オプションの全範囲は、Play JDBC reference.confにあります。

次の例外が発生する可能性があります。

Caused by: java.sql.SQLException: JDBC4 Connection.isValid() method not supported, connection test query must be configured

これは、JDBCドライバーがConnection.isValid()をサポートしていない場合に発生します。最も高速で推奨される修正方法は、最新バージョンのJDBCドライバーを使用することを確認することです。最新バージョンにアップグレードしても問題が解決しない場合は、次のようにapplication.confでconnectionTestQueryを指定できます。

#specify a connectionTestQuery. Only do this if upgrading the JDBC-Driver does not help
db.default.hikaricp.connectionTestQuery="SELECT TRUE"

詳細については、HikariCP Githubページをご覧ください。

§ボディパーサー

デフォルトのボディパーサーは、play.api.mvc.BodyParsers.parse.defaultになりました。これは、PATCH、POST、およびPUTリクエストのボディのみを解析するという点を除いて、anyContentパーサーに似ています。他のメソッドのリクエストのボディを解析するには、ActionにanyContentパーサーを明示的に渡します。

def foo = Action(play.api.mvc.BodyParsers.parse.anyContent) { request =>
  Ok(request.body.asText)
}

§最大ボディ長

ScalaとJavaの両方で、構成された最大ボディ長の処理方法と適用方法に、小さな変更ですが重要な変更がいくつかありました。

新しいプロパティplay.http.parser.maxDiskBufferは、ディスクにバッファリングする可能性のあるパーサーによって解析されるボディの最大長を指定します。これには、生のボディパーサーとmultipart/form-dataパーサーが含まれます。デフォルトでは、これは10MBです。

multipart/form-dataパーサーの場合、すべてのテキストデータパーツの集計長は、構成されたplay.http.parser.maxMemoryBuffer値（デフォルトは100KB）によって制限されます。

すべての場合において、最大長の解析プロパティの1つを超えると、413応答が返されます。これには、BodyParser.OfアノテーションのmaxLengthプロパティを明示的にオーバーライドしたJavaアクションも含まれます。以前は、カスタムの最大長が構成されている場合、RequestBody.isMaxSizeExceededフラグを確認するのはJavaアクションの責任でした。このフラグは現在非推奨になっています。

さらに、Javaアクションは、構成された最大長よりも大きいBodyParser.Of.maxLength値を宣言できるようになりました。

§JSON APIの変更

JSONルックアップのセマンティクスが少し変更されました。JsUndefinedがJsValue型階層から削除され、jsv \ fooまたはjsv(bar)形式のすべてのルックアップがJsLookupに移動されました。これらは、JsValueではなく、JsLookupResultを返すようになりました。

次のようなコードがある場合

val v: JsValue = json \ "foo" \ "bar"

プロパティが存在することがわかっている場合、次のコードは同等です。

val v: JsValue = (json \ "foo" \ "bar").get

プロパティが存在するかどうかわからない場合は、パターンマッチングまたはJsLookupResultのメソッドを使用して、JsUndefinedケースを安全に処理することをお勧めします。例：

val vOpt: Option[JsValue] = (json \ "foo" \ "bar").toOption

§JsLookup

すべてのJSONトラバーサルメソッドは、JsLookupクラスに移動されました。これは、JsValueまたはJsLookupResult型のすべての値に暗黙的に適用されます。apply、\、および\\メソッドに加えて、JSON配列にhead、tail、およびlastメソッドが追加されました。\\を除くすべてのメソッドは、未定義の値を処理するのに役立つJsValueのラッパーであるJsLookupResultを返します。

as[A]、asOpt[A]、validate[A] メソッドは JsLookup でも利用可能になったため、以下のようなコードはソースコードの変更を必要としません。

val foo: Option[FooBar] = (json \ "foo" \ "bar").asOpt[FooBar]
val bar: JsResult[Baz] = (json \ "baz").validate[Baz]

これらの変更の結果、コードは JsValue 型のすべての値が JSON にシリアライズ可能であると仮定できるようになりました。

§読み込みオプション

OptionReads は、2.4 ではデフォルトで利用できなくなりました。jsv.validate[Option[A]] の形式のコードがある場合は、次のいずれかの方法で書き換える必要があります。

JsNull と未定義のルックアップ結果の両方を None にマップするには、jsv.validateOpt[A] を使用します。これは通常、必要な動作です。
すべての検証エラーを None にマップするには、JsSuccess(jsv.asOpt[A]) を使用します。これは、2.3 での Option の読み込み動作と同じです。
JsNull を None にマップし、値が存在する場合は検証するには、jsv.validate(Reads.optionWithNull[A]) を使用します。値が存在しない場合は、結果は JsError になります。

関数型コンビネータを使用して Reads を構築する場合は、おそらく次のように置き換えることになるでしょう。

(JsPath \ "property").read[Option[String]]

次のように。

(JsPath \ "property").readNullable[String]

これは上記の (1) と同じことを行います。Writes の場合は JsPath.writeNullable、Format の場合は JsPath.formatNullable で同様です。readNullable は、最後のノードの前にノードが見つからない場合、JsSuccess(None) ではなく JsError を返すことに注意してください。

最後に、Seq[Option[String]] のように Option の Reads を必要とする型のシリアライザを作成する際に問題が発生する可能性があります。この場合、Option[String] の reads を作成し、それがスコープ内にあることを確認するだけで済みます。

implicit val optionStringReads: Reads[Option[String]] = Reads.optionWithNull[String]

§テストの変更

FakeRequest は RequestBuilder に置き換えられました。

Java テストで使用されていたリバースルーティングは削除されました。リバースルーティングを渡していた Helpers.call への呼び出しは、標準のリバースルーティング参照または RequestBuilder のいずれかを受け取る Helpers.route への呼び出しに置き換えることができます。

§Java TimeoutExceptions

Java API を使用する場合、F.Promise クラスは、Java のチェック済みの TimeoutExceptions の代わりに、チェックされていない F.PromiseTimeoutExceptions をスローするようになりました。以前に使用されていた TimeoutExceptions は、throws キーワードで適切に宣言されていませんでした。API を throws キーワードを使用するように変更するのではなく（これは、ユーザーがメソッドで throws を宣言する必要があることを意味します）、例外は代わりに新しいチェックされていない型に変更されました。詳細については、#1227 を参照してください。

旧API	新API	コメント
`TimeoutException`	`F.PromiseTimeoutException`

§WS クライアント

Scala および Java では、WSRequestHolder が WSRequest に名前変更されました。以前の WSRequest クラスは、OAuth 機能のために WS の内部でのみ使用されていたため、削除されました。

WS は AsyncHttpClient 1.8.x から 1.9.x にアップグレードしました。これには、そのライブラリを直接使用または構成する場合、多くの破壊的な変更が含まれています。詳細については、AsyncHttpClient マイグレーションガイドを参照してください。AsyncHttpClient 1.9.x へのアップグレードにより、HTTPS での Server Name Indication (SNI) が有効になります。これにより、SNI に大きく依存する Cloudflare のような HTTPS ベースの CDN で多くの問題が解決されます。

WS の構成設定が変更されました。

ws.acceptAnyCertificate は、検証なしに X.509 証明書を盲目的に受け入れるという安全でない性質をより明確に示すために、緩い設定として play.ws.ssl.loose.acceptAnyCertificate に移動されました。
ws.ssl.debug 設定は、ブール値として再定義されました。例：play.ws.ssl.debug.all=true。詳細については、SSL のデバッグを参照してください。
ws.ssl.disabledSignatureAlgorithms および ws.ssl.disabledKeyAlgorithms は、文字列の配列として再定義されました。例：play.ws.ssl.disabledSignatureAlgorithms = ["MD2", "MD4", "MD5"]。

AsyncHttpClient 1.9.x のアップグレードにより、いくつかの設定は、以前の 1.8.x バージョンの AsyncHttpClientConfig.Builder と同じ名前ではなくなりました。混乱を避けるために、WS 設定から 1.9.x AsyncHttpClientConfig.Builder へのマッピングを以下に示します。

play.ws.ning.connectionTimeout -> setConnectTimeout
play.ws.ning.idleTimeout -> setReadTimeout
play.ws.ning.followRedirects -> setFollowRedirect
play.ws.ning.compressionEnabled -> setCompressionEnforced
play.ws.ning.allowPoolingConnection -> setAllowPoolingConnections
play.ws.ning.allowSslConnectionPool -> setAllowPoolingSslConnections
play.ws.ning.maxConnectionsTotal -> setMaxConnections
play.ws.ning.maxConnectionLifetime -> setConnectionTTL
play.ws.ning.idleConnectionInPoolTimeout -> setPooledConnectionIdleTimeout
play.ws.ning.webSocketIdleTimeout -> setWebSocketTimeout
play.ws.ning.maxNumberOfRedirects -> setMaxRedirects
play.ws.ning.disableUrlEncoding -> setDisableUrlEncodingForBoundedRequests

WS は、OAuth 署名計算機を Signpost から AsyncHttpClient の OAuthCalculator に変更しました。Signpost は、リクエストトークンとアクセストークンの取得に使用されます。これはアプリケーションレベルでの変更を必要としませんが、予期しない OAuth エラーが発生した場合に注意する価値があります。

最近の TLS の脆弱性の多発により、安全でない HTTPS 構成を非推奨とする動きが活発になっています。RFC 7465 に従って、RC4 暗号スイートは非推奨の暗号のリストに追加され、デフォルトでは使用できません。これらは、play.ws.ssl.enabledCiphers および play.ws.ssl.loose.allowWeakCiphers 設定を使用して、暗号スイートとして明示的に有効にすることができます。また、TLS の IETF 推奨構成については、RFC 7525 を確認することを検討してください。

§暗号化 API

Play 2.4 の AES 暗号化は、各暗号化をランダム化するために初期化ベクトルを使用するようになりました。Play の暗号化形式は、初期化ベクトルのサポートを追加するように変更されました。

Play 2.4 で使用される新しい AES 変換の正式名称は AES/CTR/NoPadding です。古い変換は AES/ECB/PKCS5Padding でした。CTR モードは、ECB モードよりもはるかに安全です。以前と同様に、play.crypto.aes.transformation 構成オプションを設定することで、Play の暗号化変換をオーバーライドできます。Play 2.4 では、JRE でサポートされているあらゆる変換を使用できます。これには、初期化ベクトルを使用する変換も含まれます。

Play 2.4 は新しい暗号化形式を使用していますが、以前のバージョンの Play で暗号化されたデータを読み取ることができます。ただし、以前のバージョンの Play は、Play 2.4 で暗号化されたデータを読み取ることは **できません**。Play 2.4 アプリケーションで古い形式でデータを生成する必要がある場合は、Play 2.3 Crypto コードからアルゴリズムをコピーすると良いかもしれません。

以下の表は、さまざまなバージョンの Play でサポートされている暗号化形式を示しています。*古い形式* は以前のバージョンの Play で使用されます。*新しい形式 I* は、構成された暗号が初期化ベクトルを使用しない場合に Play 2.4 で使用されます。*新しい形式 II* は、初期化ベクトルが必要な場合に使用されます。

形式	エンコード	Play 2.3		Play 2.4
古い形式	hex(cipher(plaintext))	書き込み	読み取り		読み取り
新しい形式 I	“1-” + base64(cipher(plaintext))			書き込み	読み取り
新しい形式 II	“2-” + base64(iv + cipher(plaintext, iv))			書き込み	読み取り

Java Crypto API の使用方法は、出力が異なっていても同じままです。

import play.libs.Crypto;

String enc = Crypto.encryptAES(orig);
String dec = Crypto.decryptAES(enc);

Scala Crypto API の使用方法も同じです。

import play.api.libs.Crypto

val enc = Crypto.encryptAES(orig)
val dec = Crypto.decryptAES(enc)

§Anorm

新しい Anorm バージョンには、さまざまな修正と改善が含まれています。詳細については、こちらをお読みください。

§HTTP サーバー構成

高度な Netty 構成オプション（つまり、http.netty.option で始まるオプション）は、代わりに play.server.netty.option プレフィックスを使用する必要があります。

§I18n

アプリケーションがサポートする言語を指定するための構成キーが、application.langs から play.i18n.langs に変更されました。また、カンマ区切りの文字列ではなくリストになりました。例えば、

play.i18n.langs = [ "en", "en-US", "fr" ]

§Scala

i18n API を使用するには、Lang の代わりに暗黙的な Messages 値が必要になりました。Messages 型は、Lang と MessagesApi を集約します。

つまり、テンプレートを Lang の代わりに暗黙的な Messages パラメータを受け取るように変更する必要があります。

@(form: Form[Login])(implicit messages: Messages)
...

コントローラーから、暗黙的なスコープに RequestHeader 値がある限り、暗黙的な Messages 値を提供する play.api.i18n.I18nSupport トレイトをコントローラーにミックスすることで、このような暗黙的な Messages 値を取得できます。I18nSupport トレイトには抽象メンバー def messagesApi: MessagesApi があるため、コードは通常次のようになります。

import javax.inject.Inject
import play.api.i18n.{MessagesApi, I18nSupport}
import play.api.mvc.Controller

class MyController @Inject() (val messagesApi: MessagesApi)
  extends Controller with I18nSupport {

}

コントローラで、I18nSupportトレイトを持つ注入されたクラスではなく、静的なコントローラオブジェクトを引き続き使用したい場合は、より簡単な移行パスもサポートされています。上記の説明に従って、テンプレートを暗黙的なMessagesパラメータを受け取るように変更した後、次のインポートをコントローラに追加します。

import play.api.i18n.Messages.Implicits._

このインポートにより、暗黙的なスコープにLangとApplicationが存在する限り、暗黙的なMessages値が提供されます（ありがたいことに、コントローラはすでにLangを提供しており、play.api.Play.currentをインポートすることで現在実行中のアプリケーションを取得できます）。

§Java

APIはPlay 2.3を使用するコードとの下位互換性があるため、移行手順はありません。ただし、Java i18n APIを使用する前に、Playアプリケーションを起動する必要があることに注意してください。これはプロジェクトを実行する際には常に当てはまるはずですが、テストコードではアプリケーションを起動しない場合があります。テストを実行する前にアプリケーションを起動する方法については、対応するドキュメントページを参照してください。

§配布

以前は、Playはすべてのリソースを配布物のconfディレクトリに追加していましたが、confディレクトリをクラスパスには追加していませんでした。現在、Playはデフォルトでconfディレクトリをクラスパスに追加します。

これは、PlayKeys.externalizeResources := falseを設定することでオフにすることができます。これにより、配布物内にconfディレクトリが作成されなくなり、クラスパスにも含まれなくなります。アプリケーションのconfディレクトリの内容は、アプリケーションのjarファイルに含まれているという事実によって、引き続きクラスパスに存在します。

Java Persistence API (JPA)を使用している場合は、アプリケーションをデプロイするためにこのオプションをfalseに設定する必要があることに注意してください。そうしないと、エラーメッセージ：Entity X is not mappedが表示されます。これはローカル開発には必要ありません。

§Debianパッケージ作成の変更点

sbt-native-packagerがアップグレードされました。このため、以下の調整が必要になる場合があります。
* /etc/default/$appnameファイルの構文が、コマンドラインパラメータの単純なリストから、起動/停止スクリプトによってソースされるシェルスクリプトに変更され、環境変数を設定できるようになりました。
* デフォルトファイルの古い構文と同等のものは、アーカイブのconfフォルダーにあるapplication.iniファイルです。
* デフォルトファイルは、SystemV Initスクリプトでのみソースされます。Upstartはこのファイルを現在無視します。ビルドをSystemV互換のパッケージを作成するように変更するには、build.sbtにこれを追加します。

import com.typesafe.sbt.packager.archetypes.ServerLoader.{SystemV, Upstart}

serverLoading in Debian := SystemV

その他に必要な変更については、sbt-native-packagerのリリースノートを参照してください。

§その他

§OrderedExecutionContextの廃止

謎めいたOrderedExecutionContextは、レガシーアプリケーションをサポートするために、Playでいくつかのバージョンにわたって保持されてきました。これはめったに使用されなかったため、削除されました。何らかの理由でOrderedExecutionContextがまだ必要な場合は、Play 2.3ソースに基づいて独自の実装を作成できます。このクラスについて聞いたことがない場合は、何もする必要はありません。

§サブプロジェクトアセット

サブプロジェクト内のアセットは、ルートプロジェクト/異なるサブプロジェクト内で同じ名前のファイルが互いに干渉しないように、デフォルトで/lib/[subproject]に配置されるようになりました。

アプリでアセットルーティングを正しく機能させるには、次のように変更する必要があります。

GET     /assets/*file               controllers.myModule.Assets.at(path="/public", file)

これを次のように変更します。

GET     /assets/*file               controllers.myModule.Assets.at(path="/public/lib/myModule", file)

次へ: `GlobalSettings`の削除

このドキュメントにエラーを見つけましたか？このページのソースコードはこちらにあります。ドキュメントガイドラインをお読みになった上で、プルリクエストを自由に投稿してください。質問や共有したいアドバイスがありますか？コミュニティフォーラムにアクセスして、コミュニティとの会話を始めましょう。

§Play 2.4 移行ガイド

§Java 8 サポート

§ビルドの変更

§Playのアップグレード

§sbtのアップグレード

§別のモジュールでのSpecs2サポート

§別のモジュールでのデータベースエボリューションのサポート

§IDE：EclipseとIntelliJ IDEA

§Play sbtプラグインAPI

§playWatchServiceの名前変更

§Play Slickの依存関係

§Ebeanの依存関係

§バイトコード拡張

§依存性注入

§ルーティング

§依存性注入されたコンポーネント

§Scala

§Java

§GlobalSettings

§Pluginの非推奨

§構成の変更

§Akka構成

§スレッドプール構成

§HttpRequestHandler

§ロギング

§JDBC接続プール

§ボディパーサー

§最大ボディ長

§JSON APIの変更

§JsLookup

§読み込みオプション

§テストの変更

§Java TimeoutExceptions

§WS クライアント

§暗号化 API

§Anorm

§HTTP サーバー構成

§I18n

§Scala

§Java

§配布

§Debianパッケージ作成の変更点

§その他

§OrderedExecutionContextの廃止

§サブプロジェクトアセット

§`playWatchService`の名前変更

§`Plugin`の非推奨