Deployment options

Play applications can be deployed virtually anywhere: inside Servlet containers, as standalone servers, in Google Application Engine, Stack, a Cloud, etc...

Standalone Play applications

The simplest and the more robust way is to simply run your Play application without any container. You can use a frontal HTTP server like Lighttpd or Apache if you need more advanced HTTP features like virtual hosting.

The built-in HTTP server can serve thousands of HTTP requests per second so it will never be the performance bottleneck. Moreover it uses a more efficient threading model (where a Servlet container uses 1 thread per request). Different modules allow you to use different servers (Grizzly, Netty, etc...) as well.

Those servers support long polling and allow to manage very long requests (waiting for a long task to complete), and direct streaming of File objects (and any InputStream if you specify the Content-Length), without blocking the execution thread.

You will have less problems running your application this way, as you will use the same environment that you used during the development process. A lot of bugs can be discovered only when you deploy to a JEE application server (different home dir, classloader issues, library conflicts, etc...).

Please refer to the 'Put your application in production' page for more information.

Java EE application servers

Your Play application can also run inside your favorite application server. Most application servers are supported out of the box.

Application server compatibility matrix

These application server are known to work with Play 1.1 but feel free to report any other working deployment.

Deploying

You need to package your application as a war file. This is easily done with the following command:

play war myapp -o myapp.war

Please note that your application server must support deployment of exploded WAR files.

You are now ready to deploy your application.

You are advised to ‘isolate’ your Play application from the other applications to avoid version mismatches between the application libraries. This step is not standardized by the JEE / Servlet Container specification, and is therefore vendor specific.

We recommend you refer to your application server manual in order to ‘isolate’ your WAR. As an example below is how you isolate a war file in JBoss Application server. Note that this is an optional step:

Insert the following content (or create the file) in your application war directory at myapp.war/WEB-INF/jboss-web.xml:

<jboss-web>
 <class-loading java2classloadingcompliance="false">
 <loader-repository>
 com.example:archive=unique-archive-name
 <loader-repository-config>java2ParentDelegation=false</loader-repository-config>
 </loader-repository>
</class-loading>
</jboss-web>

Replace com.example:archive=unique-archive-name with whatever you wish as long as it is unique.

Datasource

Play also supports Datasource and resource look-up. To use a JNDI Datasource, configure the Play database plugin (play.db.DBPlugin) in application.conf as shown below:

db=java:comp/env/jdbc/mydb
jpa.dialect=org.hibernate.dialect.Oracle10gDialect
jpa.ddl=verify

The database plugin detects the pattern “db=java:” and will unactivate the default JDBC system.

Custom web.xml

Some application servers, such as IBM Websphere, require you to declare a datasource in a resource-ref element in the Servlet API’s web.xml configuration file. By default, web.xml is a file that is generated by Play when you execute the play war command. To customise the generated web.xml, generate the exploded WAR version, then copy the generated web.xml file to the war/WEB-INF folder in your application. The next time you will execute the play war command, it will copy your custom web.xml from to the generated folder.

For instance, to declare a datasource for IBM Websphere 7, we can declare a resource-ref in our war/WEB-INF/web.xml file:

<?xml version="1.0" ?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
        version="2.4">
  <display-name>Play! (%APPLICATION_NAME%)</display-name>
  <context-param>
    <param-name>play.id</param-name>
    <param-value>%PLAY_ID%</param-value>
  </context-param>
  <listener>
      <listener-class>play.server.ServletWrapper</listener-class>
  </listener>
  <servlet>
    <servlet-name>play</servlet-name>
    <servlet-class>play.server.ServletWrapper</servlet-class>	
  </servlet>
  <servlet-mapping>
    <servlet-name>play</servlet-name>
    <url-pattern>/</url-pattern>
  </servlet-mapping>
  <resource-ref>
        <description>Play Datasource for testDatasource</description>
        <res-ref-name>jdbc/mydb</res-ref-name>
        <res-type>javax.sql.DataSource</res-type>
        <res-auth>Container</res-auth>
  </resource-ref>
</web-app>

Google Application Engine (GAE)

A Play application can very easily be deployed to the GAE. It is a matter of installing the relevant GAE module.

play install gae

Deploying to the Google Application Engine is again really easy:

play gae:deploy myapp

Refer to the module documentation for more information.

Stax cloud hosting platform

Easy deployment to the Stax cloud hosting platform: again nothing could be easier. Install the Stax module and deploy within seconds.

Refer to the module documentation for more information.