Play cache is now split out into its own module. If you are using the Play cache, you will need to add this as a dependency. For example, in Build.scala:

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

Note that if you depend on plugins that depend on versions of Play prior to 2.2 then there will be a conflict within caching due to multiple caches being loaded. Update to a later plugin version or ensure that older Play versions are excluded if you see this issue.

The sbt namespace was previously extended by Play e.g. sbt.PlayCommands.intellijCommandSettings. This is considered bad practice and soPlay now uses its own namespace for sbt related things e.g. play.PlayProject.intellijCommandSettings.

In order to simplify action composition and filtering, the Play results structure has been simplified. There is now only one type of result, SimpleResult, where before there were SimpleResult, ChunkedResult and AsyncResult, plus the interfaces Result and PlainResult. All except SimpleResult have been deprecated. Status, a subclass of SimpleResult, still exists as a convenience class for building results. In most cases, actions can still use the deprecated types, but they will get deprecation warnings. Actions doing composition and filters however will have to switch to using SimpleResult.

Previously the stream method on Status was used to produce chunked results. This has been deprecated, replaced with a chunked method, that makes it clear that the result is going to be chunked. For example:

Advanced uses that created or used ChunkedResult directly should be replaced with code that manually sets/checks the TransferEncoding: chunked header, and uses the new Results.chunk and Results.dechunk enumeratees.

The iteratee produced by EssentialAction now produces SimpleResult instead of Result. This means filters that needed to work with the result no longer have to unwrap AsyncResult into a PlainResult, arguably making all filters much simpler and easier to write. Code that previously did the unwrapping can generally be replaced with a single iteratee map call.

Previously the constructor to SimpleResult took a Writeable for the type of the Enumerator passed to it. Now that enumerator must be an Array[Byte], and Writeable is only used for the Status convenience methods.

Previously Helpers.route() and similar methods returned a Result, which would always be an AsyncResult, and other methods on Helpers such as status, header and contentAsString took Result as a parameter. Now Future[SimpleResult] is returned by Helpers.route(), and accepted by the extraction methods. For many common use cases, where type inference is used to determine the types, no changes should be necessary to test code.

In order to simply action composition, the Java structure of results has been changed. AsyncResult has been deprecated, and SimpleResult has been introduced, to distinguish normal results from the AsyncResult type.

The signature of the call method in play.mvc.Action has changed to now return Promise<SimpleResult>. If nothing is done with the result, then typically the only change necessary will be to update the type signatures.

The way that the F.Promise class executes user-supplied code has changed in Play 2.2.

In Play 2.1, the F.Promise class restricted how user code was executed. Promise operations for a given HTTP request would execute in the order that they were submitted, essentially running sequentially.

With Play 2.2, this restriction on ordering has been removed so that promise operations can execute concurrently. Work executed by the F.Promise class now uses Play's default thread pool without placing any additional restrictions on execution.

However, for those who still want it, Play 2.1’s legacy behavior has been captured in the OrderedExecutionContext class. The legacy behavior of Play 2.1 can be easily recreated by supplying an OrderedExecutionContext as an argument to any of F.Promise’s methods.

The following code shows how to recreate Play 2.1’s behaviour in Play 2.2. Note that this example uses the same settings as Play 2.1: a pool of 64 actors running within Play’s default ActorSystem.

The stage and dist tasks have been completely re-written in Play 2.2 so that they use the Native Packager Plugin.

Play distributions are no longer created in the project’s dist folder. Instead, they are created in the project’s target folder.

Another thing that has changed is the location of the Unix script that starts a Play application. Prior to 2.2 the Unix script was named start and it resided in the root level folder of the distribution. With 2.2 the start script is named as per the project’s name and it resides in the distribution’s bin folder. In addition there is now a .bat script available to start the Play application on Windows.

Please note that the format of the arguments passed to the start script has changed. Please issue a -h on the start script to see the arguments now accepted.