This document provides an overview of the Play Framework for web application development using Java. It discusses the history and architecture of Play, how to set up a Play project, the MVC structure, routing, controllers, views, sessions, assets, hot code reloading, databases, testing, deployment, and scaling. Play uses Netty as its web server, is stateless, supports hot code reloading, and allows building asynchronous and reactive applications. It also has integrations for Akka, WebSockets, caching, internationalization, and more.

1. Web application development using Play
Framework (with Java)
Tehran JUG meeting February-2015
By: Saeed Zarinfam

2. History
 Play 1 Created By Guillaume Bort at Zengularity SA
in 2007
 Play 2 release in 2012 by Typesafe (rewrite using
Scala)
 Play 1 vs Play 2
 Part of Typesafe Activator

3. Introduction
• Inspired by Ruby on Rails and Django
• Run on JVM (use java library)
• MVC
• Stateless
• Hot code reloading (in development)
• Convention over configuration
• Lightweight
• Asynchronous and Non-blocking I/O
• Java 8 support

4. Architecture
• MVC architecture
• Netty as web server (no servlet container)
• Sbt as build tools (Ivy dependency manager)
• Stateless

5. Requirements
 Install Typesafe Activator (or sbt)

JDK 6 or later

activator new my-first-app play-java
 Open project in IDE (Eclipse and Intellij)

Run using
– command line (activator run)
– Activator console (activator)
– Activator UI (activator ui)
– Interactive Console (Only in Scala)

6. Activator UI

7. Project structure
• App
• Public
• Conf
• build.sbt
• Scala and Java
• ...

8. Route
• Scala syntax
• Optional parameters
• Reverse routing
• REST friendly

9. Controller
• Actions return Result
• Static method
• Use dependency injection (JSR 330 in Play 3)
• HTTP manipulation (body parsers)
– REST service (JSON and XML)

10. View
 Type safe template engine
 Scala Template (Twirl inspired by ASP.NET
Razor)
 Http form handling

11. Session
 Session data are not stored in the server
 Session data added to each subsequent HTTP
Request, using Cookie.
 Cookie are signed with a secret key so the
client can’t modify the cookie data or it will be
invalidated
 Use cache for sever side session data

12. Assets
 Public Assets
 WebJars
 Assets controller
 Etag

Gzip
 Caching
 Managed Assets
 CoffeeScript
 LESS CSS

Sbt-web plugins

js-engine plugin (able to execute plugins written to the Node API either
within the JVM via the excellent Trireme)

13. Hot code reloading (in
development)
 It is possible because Play is stateless and tightly integration between Play and sbt
 Classloader hierarchy manage by sbt

Tricky (You don't need JRebel)
 For each request reloader check if there's any code changes
 Compile changed codes
 remove the old application classloader
 create a new application classloader with the updated classes.
 restart application (only application, no need to restart the JVM)

14. Accessing Database
 JDBC
 JPA (2.0)
 Ebeans (default ORM)
 Database evolutions
 Connection Pool
 Transaction
 In-memory H2 database

15. Asynchronous
 Actions are asynchronous by default
 Each open connection does not need a thread
 application code should avoid blocking in
controllers

16. Other APIs

Integration with Akka

WebSockets and Comet sockets

Cache API

Internationalization

Interceptors

Filters(only in Scala)

JSON API (jackson)

XML API

Job scheduling (Using Akka)

Logging API (Logback)

17. Testing

Ready to use application stubs for test (several helper methods)

Junit

FEST assertions

Mock

Test every part of your application (router, action, controller and ...)

Testing with a browser using FluentLenium ( Selenium WebDriver
wrapper)

18. Plugins
 Several plugins
– Mail
– Open ID
– CRUD
– Security

19. Deployment
 Compile all class and assets in application
 Activator start
 Activator stage (without any dependency on Play)
 Activator dist (produces a ZIP file without any
dependency on Play)
 SBT Native Packager plugin(activator universal:package-
bin)
– MSI, OS X disk image, RPM, DEB and …
 Publishing to a Maven (or Ivy) repository

20. Scaleability
 Scale horizontally easily (using load balancer)
 Integrate with Akka clustring and remoting
features
 Asynchronous from bottom to top

21. Reactive

Play Iteratee library (Scala Library)

ReactiveMongo

22. Non-blocking
 ReturnPromise<Result>Promise<Result>
 Intensive computation will just be run on another thread
(thread pool in separate execution context ).
 The web client will be blocked while waiting for the
response, but nothing will be blocked on the server

23. ‫تشکر‬
zarinfam.s@gmail.com
http://javabyab.com