What is the best Playframework 1.x deployment strategy?

Question

I have developed a small application based on Play Framework (I am still learning). Now I need to bundle it for shipping. One way is to create a war file and deploy it in a servlet container such as tomcat- That is very clear from the docs. The other option is to use the built in http server. This is what I want to do since it is the recommended way.

Now how do I pull off the application from my development application so that I can deploy it into the production server - I mean how do I compile and produce a bundle that can be distributed to my client who will do something like unzip the distribution parkage and run a script to start the server?

Or I put it this way, do I need to set play path on my production server, then copy my project files to the production server so that my user can run it using play run, as I have been doing in my development environment?

The docs only say that I need to change to production mode.

Answer 1

Let me settle a few things said. Not necessarly wrong but certainly inexact :

You definitly need to have play in your environment variable

No, you don't. Play comes as a folder containing a bunch of scripts. All plays needs is Java installed and JAVA_HOME defined. I even think, you can define Java via command line. You could call play with an absolute path without evironment variable. For instance, you could even deliver the framework along the application.

If you want automatic deployment there is IMHO no way around a WAR file.

Incorrect. I use automatic deployment for all my play apps via Hudson/Jenkins and I don't use WARs. A Play application is nothing more than a folder containing Java sources and configuration files. You could package those as a ZIP/TAR/RAR/whatever format you want and use scripts to run/install those.

On the other hand you don't need the Framework on your production server when building a WAR file.

Incorrect, since the play war command actually bundles the whole framework in the WAR. So you still have it, simply it is included in your WAR and not installed somewhere on your server.

Further, as was discussed here, the best deployment strategy for play is to use it's standalone jetty configuration. IMHO, Tomcat should be used in last resort and/or only if there are legitimate reasons to do so.

EDIT: the referenced question suggests to use standalone Jetty only in that particular case (as a replacement for Tomcat). If it is an option for you, THE BEST deployment strategy is the same HTTP server that comes bundled with Play! (it is based on Jboss Netty). Why? It does not use Servlet API and thus it does not have the thread-per-request limitation - this allows Play! to do some clever tricks with asynchronous IO (Play! continuations), see this thread for details.

Note: although Jetty/Tomcat supports asynchronous IO also, they support it through their own proprietary APIs - if you package your Play! app as WAR, it does not take advantage of those APIs. So, if you package your app was WAR be prepared to see lots of threads sitting idle in the server. Async IO was standardized with Servlet API 3.0 and Play! 2.0 will take advantage of that. Meanwhile, your best option is to stick with built-in server.

Answer 2

You definitly need to have play in your environment variable if you don't want to build a war file, because running it on your production server requires 'play start MYAPP' (starts the app and puts it in a background process). The App does not run standalone without the framework itself.

I mean how do i compile and produce a bundle that can be distributed to my client who will do something like unzip the distribution parkage and run a script to start the server?

Well, this is precisly what the war file is for. If you want autmatic deployment there is IMHO no way around a war file. On the otherhand you dont need the Framework on your production server when building a war file. You could bild the war with play war and the distribute it to your production server (if it is a tomcat) using the maven tomcat plugin.