Play 2 is a Web framework specific to Java and Scala, it is based on a lightweight, stateless and Web-friendly architecture, moreover, it is an implementation of Akka, an engine for building competing, distributed, highly scalable and Fault-oriented applications -Tollerance.
Installation
We start by downloading the package from the official website of the project, but in the page is shown the main package with the activator, download instead of the 108 mega version in the link located under the old version entry:

Once downloaded, the package will be unpacked into a folder, in our case below c, to then add the path to the installation folder to the system path variable:

Then open a Dos shell and type play help, should appear a message like the one shown in the figure:

Now let’s position play new MyPlayAppourselves under the folder c (the root) and type this will launch a text mode wizard to create our first Web application:

The application will be created after making the simple choices that the wizard requires, if indeed we open the folder below:

The folder is organized according to a predefined structure, this mode clearly reminds the Convention Over Configuration widely used by Maven and beyond. Now we import our application into Eclipse, then place ourselves under the folder of our application and type play Eclipse. It should be noted that the command will not work correctly if we navigate through a proxy, in this case we must set the environment variable HTTP_PROXYwith the value of our proxy (for example http://<proxy_name>:port:) and launching the command by adding any credentials (for example:) play Eclipse -Dhttp.proxyUser=<user> -Dhttp.proxyPassword=<password>.

Once the application has been imported, the following problem may occur:

The solution is rather simple just open the file .classpathand remove the part marked in red in the next image:

We will refresh the application in Eclipse and the error will disappear.
Starting the server
Now let’s start the server, then type the command from the Dos shell
play ~run
Digitamo then in the browser URL: http://localhost:9000/; the welcome screen of our server will appear:

Note: in some cases, you may have to shut down the server. While with the first release of the fremework it was enough to type the command play stop, version 2 instead requires a work-around that consists in creating a file stop.bat(also in the same folder of the project) bearing the following content:
@echo off if exist RUNNING_PID ( setlocal EnableDelayedExpansion set /p PLAY_PID=<RUNNING_PID echo killing pid !PLAY_PID! taskkill /F /PID !PLAY_PID! del RUNNING_PID endlocal )
This script will stop the server when necessary.
Routing and Rendering
Our application is already running, we did not specify the classic Context Root, but the engine recognizes that the reference application is ours because we have launched the command play rununder the directory MyPlayApp.
Play foresees the presence of a controller that transmits HTTP requests to its own called method action; confthe file is included under the folder routes, containing the URL mapping with the corresponding actions:

The main controller called is located under the package controllers:

the method index()is instead the one that is called when the GET request is made, while the ok enetered index message will be displayed on our output page:

The output rendering is based on Scala and uses two templates:
- index.scala.html
- main.scala.html
The first template (whose content is proposed in the following snippet) collects data passed via HTTP and communicates it to the second:
@(message: String) @main("Welcome to Play") { @play20.welcome(message, style = "Java") }
messageit is the message passed by the controller which is then made available to the second template; this instead the content of the template main.scala.html:
<pre class=”brush: php; html-script: true”>
@(title: String)(content: Html)
<!DOCTYPE html>
<html>
<head>
<title>@title</title>
<link rel=”stylesheet” media=”screen” href=”@routes.Assets.at(“stylesheets/main.css”)”>
<link rel=”shortcut icon” type=”image/png” href=”@routes.Assets.at(“images/favicon.png”)”>
<script src=”@routes.Assets.at(“javascripts/jquery-1.9.0.min.js”)” type=”text/javascript”></script>
</head>
<body>
@content
</body>
</html>
</pre>
Then try adding a custom routing by inserting the following line in the file routes:

Once the controller is open, you will have to associate an action with the added path:

It is thus specified to the Play engine that by typing http://localhost/hellothe hello()controller method must be called and the message ok entered hello displayed accordingly:

Everything will happen in real time, without the need for compiling and re-deploy .
Testing with Junit
Play 2 uses Junit for testing and also checks the availability of a controller action; to test if our action hello works correctly, we open the class ApplicationTest.java under the package text and add the following code:
@Test public void callIndex() { Result result = callAction(controllers.routes.ref.Application.hello()); assertThat(status(result)).isEqualTo(OK); assertThat(contentType(result)).isEqualTo("text/html"); assertThat(charset(result)).isEqualTo("utf-8"); assertThat(contentAsString(result)).contains("ok entered hello!"); }
It specifies that by calling the action controllers.routes.ref.Application.hello(), the response must be positive and that the reply message must contain the expected string:
