Take the 2-minute tour ×

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.

share|improve this question
add comment

2 Answers

up vote 3 down vote accepted

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.

share|improve this answer
Thanks for the answer. Is it advisable to do use the war ? there is something on the war file about one thread per request limitation. Does the war file work as good as inside the play framework? something else, if i decide to deploy the play framework alongside my application, How do i remove the source code so that i distribute the compiled classes only? Josh. –  joshua Mar 12 '11 at 12:40
I have a little Application in a Glassfish Application Server which is running stable. It hasn't much Traffic so i can't tell how good it perforamcne. Guillaume mentioned on the Mailing List that using a Play App is the recommended way. You dont have to remove the source code. Redeploying will do the job for you. –  svenkubiak Mar 12 '11 at 18:21
@joshua if you don't want to distribute source files, so that your code is protected from clients, the answer is to 1) take a copy of your app, 2) use 'play precompile MYAPP' to compile all your source code, and then 3) you can delete the source code folder. Your app is now ready to ship! Obviously don't delete the source code from your original, unless you have it backed up elsewhere! –  Codemwnci Apr 25 '11 at 7:43
add comment

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.

share|improve this answer
What are the problems of deploying a play app in a servlet container ? speed? some features wont work? what are the actual issues? –  joshua Aug 30 '11 at 4:58
First of all a servlet container loads a lot of components that aren't needed by Play, creating a memory overload. Second in order to deploy a play on in a server container, you need to build a war. During that conversion errors can occur (especially if relying on modules, external jars, libs). Another risk to take. Performance is also an issue. A servlet container will do additionnal processing. A lightweight container such as the built in Jetty is more than enough. There are many reasons, this are IMO the most important. –  i.am.michiel Aug 30 '11 at 9:37
But the upside is that you can use Filters and also your corporate overlord will allow your app to be deployed in their infrastructure (jetty? bah!) –  Damo Dec 15 '11 at 3:43
Nice additional informations Neeme ;) –  i.am.michiel Jan 16 '12 at 19:31
add comment

Your Answer


