Play Framework application bind address and port

I have recently begun experimenting with the Play Framework and I think it is great. Definitely something worth looking into. This post is based on my experience with Play 2.1.2, but I am convinced that it applies to 2.0.x versions as well (and quite possibly to older versions too). I am using an embeded Netty server that is a build in default server in Play Framework.
Play works just fine if you are satisfied with the defaults, but the alternative configuration can pose a challenge.
The default bind address is 0.0.0.0:9000 and it fine, but I needed it to change to meet the OpenShift's demands. I wanted to bind a Play application on one specific address along with a non standard port.
The configuration described in the Play's documentation works, but only from the Play's console and I needed to launch the application directly from the command line and that is where I got stuck for quite a while. And this is what I found out.

If you want your application to bind to a different port and address while launching it directly from a command line by a following command, you have to use a quotation marks to group all the parameters together.
This is how you start your application using defaults (0.0.0.0:9000).

$ play start

This is how you bind your application to the 8080 port (still all addresses).

$ play "start 8080"

And finally this is how you bind the application to a specific address and a port.

$ play "start -Dhttp.port=1234 -Dhttp.address=127.0.0.1"

Please note that the quotation marks are vital. You don't need them when you are launching your application from the Play's console, but you have to use them from the command line. If you omit the quotation marks, everything after the first word (start in this case) is disregarded.

Comments

Post a Comment

Popular posts from this blog

I recently deployed Jenkins CI on my personal server. The hardest question was what security solution should I use. As title of this post may have suggested I have chosen to use the infrastructure I already have ... LDAP. Now I would like to describe, how easy this configuration is and how it works.

My LDAP structure
My base dn is dc=effy,dc=cz. And it contains two organizationUnits ... ou=people (to hold users) and ou=groups (to hold user roles). Groups (Roles) are presented by objectClass groupOfNames, they are identified by cn. People (Users) are of objectClass inetOrgPerson, thus identified by uid.

Most of the applications I work on are based on jsp's and usually run on Jboss AS of various versions. And even though the newer applications are maven based and run on Jboss AS 7, almost nothing have changed in a matter of development. At least I thought that nothing have changed, but that was only because my carelessness.
When you are developing web tier, there is no compiler telling you what is wrong in the real time, you depend on syntax validation only. And that enables you to do a lot of small mistakes that usually end up with error 500 and a need to redeploy the application.
But this is the case only until you discover the right configuration!

I believe that every programmer understands the need for testing. We want our code to be tested and bug free, but the time is of the essence. We need tests to be easily written and executed and as exact as possible.
From my experience, testing Java EE always required a special treatment. You could either code additional means to enable launching tests from your application, or you were left with creating a test environment using for example OpenEJB for beans, something different for transactions and something else for persistence. The second approach is better, because it is more manageable and transparent, but it's downside is that the tests are run in a different environment than the one used as runtime. This means that not everything that works in tests will work when deployed on server and vice versa.