I've decided to go with Apache as the http server in front of my play app. The server team at my company says they installed Apache and Python and play on the target server. I'm code complete, so here's where I don't know what to do next.
How do i "compile" my play java app?
What folders do I deploy, which ones do I not deploy?
Where on the target server hard drive do I place the webapp I'm deploying?
How do i tell apache where I deployed the play webapp to on the disk?
How do I make it so that apache and play are now always running and don't require I be logged in on the target server?
Yeah I'm new to linux
Please help I'm lost.
Thanks in advance
Josh
Read the Preparing for production section before anything else.
How do i "compile" my play java app?
Play does that for you when you laucnh play start. However you can use the play precompile command before starting the app.
What folders do I deploy, which ones do I not deploy?
app, conf and public. You might have some 3rd party lib dir too.
Where on the target server hard drive do I place the webapp I'm deploying?
I don't think it really matters.
How do i tell apache where I deployed the play webapp to on the disk?
Apache act as a reverse proxy (forwards every requests to your app and serves the reponses back to client). For this you need to edit the apache's httpd.conf
How do I make it so that apache and play are now always running and don't require I be logged in on the target server?
You need to start the apps as daemon threads which I think apache does by default. the command play start should run play in the background.
Related
I have developed a Scala/Play webapp and now I am trying to deploy it on production.
What is the recommended "best way" of doing that?
The documentation mentions only runnig it from play console, which does not seem very robust (in case of machine restarts etc).
There are apporaches to wrap the app into a war file and deploy on Tomcat7 (e.g. play2war), but they do not seem to be actively developed (e.g. there is only beta support for 2.3, the plugin is not available from maven repo etc).
What is the right way of doing this?
If you host the application on Windows then take a look at Yet Another Java Service Wrapper which wraps the application in a Windows service that will keep it running, even after restarts.
If you run it on Linux then take a look at Supervisord and Monit, which monitors the application and starts, restarts and stops it when needed.
See the following links for tutorials:
How do I run a Play Framework 2.0 application as a Windows service?
http://marcovanduijn.blogspot.nl/2011/08/run-play-framework-application-as.html
http://blog.fgribreau.com/2013/09/how-to-make-play-framework-2-work-with.html
I'm building a web app with Backbone.js (I'm not tied to Backbone yet though). I need a back-end framework only for persistence to a database via a RESTful API. However, I also need to able to deploy it as a 'desktop' app for off-line use, i.e. running a local server and launching a browser window, but I don't want users to have to start a server from the command line to run the application.
I can use SQLite as a database since it's only a single user application, it's just the framework that I'm stuck on. I have looked at the following:
Rails and Django: Default web servers are too flimsy, requires Ruby/Python and runs from the command line. I'm aware of the Bitnami stacks but at 99mb it's too big of a dependency and not exactly hidden from the user.
Sproutcore: Run from command line, also too bulky.
Pyjamas Desktop - Depends on MSHTML which I suspect limits my ability to use HTML5 features.
I'm leaning towards creating a Java app that starts a Scala/Lift server instance and opens a web browser, then sits in the system tray (kind of like WAMP). Is anyone familiar with a tool or framework built for user-friendly deployment as a standalone desktop app?
I do not know if PHP is an option for you? Then I would recommend phpdock.
web2py has a standalone deploy-to-desktop feature with no dependency on Python: http://web2py.com/books/default/chapter/29/14#How-to-distribute-your-applications-as-binaries
As Eydun said, phpdock is an option but it's commercially licensed .
I settled on using Java/Spring/H2/Hibernate/Jetty. I find that Jetty serves requests VERY quickly so the application looks real-time when launched in a browser. There is a tutorial on embedding the Jetty server here. I imagine it's quite trivial to build a GUI that launches the server and a browser.
Another Java option is to use the Play Framework, which may be more at home to those coming from a Django/Rails background. However, the documentation for "creating a standalone version of your application" for Play 2.0+ indicates that they have ditched using Java EE containers (Tomcat/Jetty) and WAR files in favor of running the JARs with the bundled copy of JBoss Netty, so it may take a bit of work to get it running the way you want it.
I would recommend the Play Framework approach if you're OK with using/learning Scala.
Building a Play 2.0 scala app and deploying it to the ROOT context on Tomcat (from what I understand, a Play app must be deployed to ROOT context). There are other web apps running on this server at different contexts, but with the Play app at root, it is intercepting every request and failing if it is a route it does not understand.
Is there any way to have Play ignore a route in order to have Tomcat continue dispatching it to a servlet that is registered for that context?
thanks,
brian
In fact the limitation you have seams to be linked to sub-context deploiement. The play2 war plugin does not support it until Play 2.1
It could be possible to trick with tomcat conf to do what you want. I don't know tomcat enough to give you the right conf.
You can still deploy your Play app as a standalone app (not embedded in Tomcat) and use a front-end HTTP server to handle reverse-proxy to the right HTTP server. You will have to define for each HTTP server the right port to run on and then configure your reverse-proxy to route the request depending on the domain/port to the right local port. I use Nginx for that. Maybe Tomcat can handle this also.
Actually, it turns out that this was not a problem after all. I had inadvertently not had the other apps deployed in the same tomcat server I was testing with (doh!). Once I deployed them properly, then the Play Framework app got the requests that were correctly bound for it and the other apps got the requests that were bound for them in the sub-contexts. So, false alarm.
In fact, I'm trying to see which would be the best approach to achieve play framework native support on openshift.
Play has it's own http server developed with netty. Right now you can deploy a play application to openshift, but you have to deploy it as a war, in which case play uses Servlet Container wrapper.
Being able to deploy it as a netty application would allow us to use some advanced features, like asynchronuos request.
Openshift uses jboss, so this question would also involve which would be the recommended approach to deploy a netty application on a jboss server, using netty instead of the servlet container provided by jboss.
Here is request for providing play framework native support on openshift There's more info there, and if you like it you can also add your vote ;-)
Start with creating 'raw-0.1' application.
SSH into the server and
cd $OPENSHIFT_DATA_DIR
download and install play into a directory here. $OPENSHIFT_DATA_DIR is supposed to survive redeploys of your application.
Now you can disconnect from SSH.
Clone the application repository. In the repository, there is a file .openshift/actions_hooks/start. It's task is to start the application using a framework of your choice. The file will need to contain at least (from what I know about Play)
cd $OPENSHIFT_REPO_DIR
$OPENSHIFT_DATA_DIR/play-directroy/play run --http.port=$OPENSHIFT_INTERNAL_PORT --some-other-parameters
Important
You have to bind to $OPENSHIFT_INTERNAL_IP:$OPENSHIFT_INTERNAL_PORT. Trying to bind to different interface is not allowed, also most of the ports are blocked.
To create some sort of template, save the installation steps into .openshift/action_hooks/build file. Check if play is installed, if it is do nothing, if it's not, execute the installation process.
I have a J2EE application that runs fine and is accessible to the internet. Some of our prospective customers would like to use it, but are unwilling to send their data over the internet.
As a workaround I've thought of providing them with the war file and letting them run it themselves.
The problem is: how do I make it trivial for them to update the application when I make a new version available? The more difficult it is, the less likely they are to buy in.
What's involved in writing an updater that fetches the latest war file from online and updates the web application? Is this even possible?
In the least they would need to redeploy the war file. Most application servers have an interface through which you can upload a new war file. I am in favor of doing this process manually i.e. you send them a war file and they can use the app server's admin page to deploy the new war. This way they explicitly know when they are updating the app. Also they control when they want to deploy a new version of the app and easily roll back to an older version.
I would recommend using Jetty as an embedded solution. I have used a few apps that that use the embeded functionality. It allows you to create a packaged distribution of your application that runs a servlet container out of the box.