Books

The whole runtime API for Play have been migrated to Scala 2.10 allowing your applications to take part of the new great features provided by this new language release.

In the same time we have broken the dependency that was existing between the Scala version used by the Build system (sbt), and the Scala version used at runtime. This way, it makes it easier to build and test Play on experimental or unstable branches of the Scala language.

One of the greatest feature provided by Scala 2.10 is the new standard scala.concurrent.Future library for managing asynchronous code in Scala. Play is now based itself on this API, and its great asynchronous HTTP and streaming features are now compatible directly with any other library using the same API.

It makes it even simpler to use Play with Akka, or any upcoming asynchronous datastore driver that will use this new API.

In the same time, we worked to simplify the execution context model, and by providing an easy way to choose for each part of your application, the underlying ExecutionContext used to run your code.

To allow, to compose and reuse components in your own projects further, Play 2.1 supports sub-Router composition.

For example, a sub project can define its own router component, using its own namespace, such as:

In conf/my.subproject.routes

GET / my.subproject.controllers.Application.index

And then, you can integrate this component into your main application, by wiring the Router, such as:

# The home page
GET / controllers.Application.index
# Include a sub-project
-> /my-subproject my.subproject.Routes
# The static assets
GET /public/*file controllers.Assets.at(file)

In the configuration, at runtime a call to the /my-subproject URL will eventually invoke the my.subproject.controllers.Application.index Action.

Note: in order to avoid name collision issues with the main application, always make sure that you define a subpackage within your controller classes that belong to a sub project (i.e. my.subproject in this particular example). You’ll also need to make sure that the subproject’s Assets controller is defined in the same name space.

While running asynchronous code over mutable data structures, chances are right that you hit some race conditions if you don’t synchronize properly your code. Because Play promotes highly asynchronous and non-blocking code, and because Java data structure are mostly mutable and not thread-safe, it is the responsibility of your code to deal with the synchronization issues.

In this code, chances are really high to hit a race condition if the 2 callbacks are run in the same time on 2 different threads, while accessing each to the share result HashMap. And the consequence will be probably some pseudo-deadlock in your application because of the implementation of the underlying Java HashMap.

To avoid any of these problems, we decided to manage the callback execution synchronization at the framework level. Play 2.1 will never run concurrently 2 callbacks for the same Http.Context. In this context, all callback execution will be run sequentially (while there is no guarantees that they will run on the same thread).

By default Play binds URLs to controller methods statically, that is, no Controller instances are created by the framework and the appropriate static method is invoked depending on the given URL. In certain situations, however, you may want to manage controller creation and that’s when the new routing syntax comes handy.

Route definitions starting with @ will be managed by the Global::getControllerInstance method, so given the following route definition:

GET / @controllers.Application.index()

Play will invoke the getControllerInstance method which in return will provide an instance of controllers.Application (by default this is happening via the default constructor). Therefore, if you want to manage controller class instantiation either via a dependency injection framework or manually you can do so by overriding getControllerInstance in your application’s Global class.

As this example demonstrates it, it allows to wire any dependency injection framework such as Spring into your Play application.

The support of content negotiation has been improved, for example now controllers automatically choose the most appropriate lang according to the quality values set in the Accept-Language request header value.

It is also easier to write Web Services supporting several representations of a same resource and automatically choosing the best according to the Accept request header value: