Using antify to run your Play application with ant

Since the version 1.2.2 of Play the antify module has been part of the framework.

Here is how you can run your Play application with ant:

  1. Generate the build.xml file
    /home/huljas/test-app>play antify
    ~        _            _
    ~  _ __ | | __ _ _  _| |
    ~ | '_ \| |/ _' | || |_|
    ~ |  __/|_|\____|\__ (_)
    ~ |_|            |__/
    ~ play! 1.2.2,
    ~ OK, a build.xml file has been created
    ~ Define the PLAY_PATH env property, and use it with ant run|start|stop
  2. Set the PLAY_PATH environment variable
    /home/huljas/testapp>export PLAY_PATH=/usr/local/play-1.2.2
    /home/huljas/testapp>echo $PLAY_PATH
  3. Now you can run your application with ant!

    Check the main targets:
    /home/huljas/testapp>ant -p
    Buildfile: /home/huljas/testapp/build.xml
    Main targets:
     auto-test   Automatically run all application tests
     precompile  Compile all java sources and templates
     run         Runs the application
     start       Starts the application as a daemon
     stop        Stop the application daemon
     test        Run the application in test mode

    Run you application

    /home/huljas/testapp>ant run
    Buildfile: /home/huljas/testapp/build.xml
        [java] Listening for transport dt_socket at address: 8000
        [java] 23:06:22,366 INFO  ~ Starting /home/huljas/testapp
        [java] 23:06:22,806 WARN  ~ You're running Play! in DEV mode
        [java] 23:06:22,876 INFO  ~ Listening for HTTP on port 9000
    (Waiting a first request to start) ...

IE Unable to modify the parent container OR 800a03e8 error

Recently I encountered the following error with IE which left me puzzled and the page unfinished:

Message: HTML Parsing Error: Unable to modify the parent container element 
before the child element is closed (KB927917)
Line: 0
Char: 0
Code: 0

With the Javascript debugger I found a different message:

Could not complete the operation due to error 800a03e8

And what was even more weird was that the page worked fine not only with FF and Chrome but also with IE7 and IE9 and most versions of IE8 too! There were only TWO computers with IE8 in the office where we were able to reproduce the problem.

So after some digging (This took a while because that particular line was a 3rd party Javascript using document.write() so I couldn't modify it NOR wrap it inside a ready handler) I was able to conclude that the line where the debugger caught the error was not the cause of the error.

With that information I was able to trace the problem to another Javascript, which was missing the ready handlers. When I wrapped the code inside $(function() { ... }); the problem was solved.

Lesson learned? Always use the jQuery ready handler, it can save you a lot of trouble!

Useful formats for Java Formatter

Some examples of using String.format(..) which are documented in a kinda complicated manner in the docs.

Five checks for a well performing application

To get started you will need a Performance test client like JMeter and setup some test cases for your app. I'd recommend you start by running the app on your local machine, because once it works OK there you can check it in a more production-like setup.

So assuming that you know how to run your tests lets move to our first check.

CHECK 1: Is it fast?

First we will run our test cases with single thread only. This is also a good test to see that our test cases are working at all! While the test is running we will monitor the Average response time reported by the test client.

If the measured value doesn't meet our expectations we will try to fix the problem and rerun the test again.

Remember that to make the fixing part easier you should keep your test cases as simple as possible!

CHECK 2: Does it scale?

Next we are going to increase the number of threads in our test to verify that our app is the true multithreaded beast its supposed to be! In order to do this we will start our test and slowly increase the number of threads while watching the Throughput of our app.

Once adding more threads doesn't increase the throughput anymore we have reached our Maximum throughput.

Next we will check the CPU usage of our setup with a monitoring tool like top. If the CPU usage is not at 100% we will need to find the bottleneck and fix it. And then rerun the test.

We are making the naïve assumption that our app is CPU intensive because it probably should be.

Once the CPU is screaming we will check that the throughput meets our expectations factoring in the difference between our local setup and the production setup, fixing the issue if it doesn't.

Check 3: Does it behave?

Now we are going to keep the load to our application at the max and check that A) responses are still fast enough and B) there aren't any big jumps in them.

So keep the test running at the maximum throughput and check the reported Average response time and Maximum response time. If they are not OK, find the problem and fix it and then rerun the test.

Fixing any issues with the Maximum response time is going to be really difficult unless you have some system monitoring in place. A really good tool for that is Jamon.

Check 4: Does it stay overnight?

Now we are going to let our test run overnight to see if our app stays up overnight. Since you can do this only so often it is recommended that for this step your test cases should cover as much of your apps usage as possible.

I would recommend that you run your test at the maximum since it will help you to see the underlying problems faster. What we are expecting here is that our app will maintain it's performance steadily through the whole night.

We are mostly concerned about memory leaks here so if you're logs are full of OOM in the morning you need to check your applications memory usage with a tool like jhat.

Don't forget to check your log files for both possible errors and size. You wouldn't believe how many times my test runs have failed because the log file gets too big!

And once your app stays up overnight it's time to extend the invitation and see does it stay over the weekend.

Check 5: Does it recover?

As a last step we will check that our application recovers from a basic failure.

So we will run out test just as we did in our previous check at the max with mixed test cases. While the test is running we will restart our app and verify that everything will continue as before once it is back up, checking the logs for any errors.

And once that is done repeat the test by restarting other services your app depends on.

Spring property configurer for multiple environments

Here's a spring bean configuration snippet I use for configuring my spring application. By default it loads the configuration from the, which is used for local development. For for production and staging environments you can override it with a system property

Managing database with Play Carbonate module

Managing the database is important aspect of modern application development, typically done with database migrations. I used migrations before I started working with play so naturally the first module I wrote for it was a database migrations module with my favorite migrations library, Carbon Five Migrations.

The initial version of the module was really basic and after a twenty or so models created and equal amount of copy-pasted create table statements I got this idea of updating my module with the Hibernate schema update. And the result of that is the Play Carbonate module.

Remember that the schema update is just a tool. Always check the SQL it generates!


To use the module add the module to your application.conf file


Next configure the database and add the carbonate path in to the application.conf file, in this example we are using id local-mysql

Now our carbonate module is configured and ready to use.

Usage example

Now lets consider a simple model shown below We will run the carbonate:new command to generate a new database migration file

play carbonate:new --%local-mysql
We open the file and format it a bit and add a semicolon to the end, in general we make sure that it is what we want.

To run the migration we just start our play application

play run --%local-mysql
22:08:20,709 INFO  ~ Running migrations from path conf/migrations
22:08:20,757 INFO  ~ Migrating database... applying 1 migration.
22:08:20,758 INFO  ~ Running migration 20110404220338_simple_model.sql.
22:08:20,812 INFO  ~ Migrated database in 0:00:00.250.

Now we need to change our model a bit, we want to add a category for our entity. So after the change we run the carbonate:new again

play carbonate:new --%local-mysql

And again after some formatting and most importantly adding the semicolons our migration looks like this

In general you should split every SQL statement to its own migration to avoid trouble in the case they fail. Here we keep them in single file to keep this example short and readable.

To apply the migration we run our application again

play run --%local-mysql
22:19:28,016 INFO  ~ Running migrations from path conf/migrations
22:19:28,058 INFO  ~ Migrating database... applying 1 migration.
22:19:28,059 INFO  ~ Running migration 20110404221245_added_category_for_the_entity.sql.
22:19:28,439 INFO  ~ Migrated database in 0:00:00.380.

Localizing your Play application with @messages

I wrote this module to help me with the localization of our application. I used to have similar tool in our old struts based system, so I first copied it to play and later rewrote it all together. I even forced myself to learn regexp, which I have been trying to avoid so far ;).


First you need to add the module to your application.conf:

module.messages=path to the module
Then you need to add the module routes to your application routes:
*    /    module:messages
Now you need to restart your application and then you can access the tool at @messages:

Managing existing keys

This is the tab where you can modify the existing keys, keys that are found in sources and messages. Header section has selection for the language to edit and another for the language to compare to. Keys can be removed by checking the remove check box.

The keep check box is reserved for valid keys that the tool doesn't find in the sources, for example keys that are generated in code.

Localizing new keys

New keys are those keys that are found in the sources but are not yet localized in the messages file.

Since we are not sure about the first key we click on the key to check the sources. From the sources we can see that this key is in fact part of a generated key. We choose to ignore this key, meaning that it will no longer be shown in the new keys list in any language.

After save we can find the key in the ignored keys section. Ignored keys are saved in the messages.ignore file.

Checking obsolete keys

Obsolete keys are those keys that are in the messages file, but cannot be found in the sources.

We mark keys that are valid with the keep check box. These keys will be added to the keep list and will be displayed among the existing keys. The keep list is saved in messages.keep file.

Keys that are old can be removed by checking the remove check box.


You can find the sources at github here

Migrations to Play: Why not use Hibernate Schema Update?

First module I wrote for Play framework was a database migration module based on c5-db-migration. It's really simple, it has play command for creating a new migration file using timestamp for versioning. And then it has plugin, which loads the migrations to the database on application startup.

So after using the module for 2 months I got this idea on how I might be able to improve it: Since hibernate can generate the database changes if you configure the jpa.ddl=update, why not use the hibernate schema update to generate the changes to a migration which you could then review and adjust manually if needed?

After some exploration on the hibernate sources and plenty of trial and error I ended up with the following code:

It prints the update statements to System.out after comparing the database with the models. It also reads the hibernate configuration from the application.conf which is important for me since we use a custom naming strategy. Next step is to add this to our migration module.

Running your play application with ant

I've been lately using Play framework for upgrading our software to the next level. I have to say I like it a lot, it feels like warm summer breeze after a long winter of Liferay development.

Biggest problem I've had with it so far has been integrating it with our Hudson continuous integration environment. The play command used for everything is written in Python. I wanted to use ant since Hudson has good support for it and ant is also platform independent, which is important to me since I'm developing on windows and our continuous integration is Linux.

So after some digging of the play scripts and few print statements later (first time with python for me), I was able to come up with the following ant task to run my play application:

  <target name="play-run" description="Runs the application">
        <java classname="play.server.Server" fork="yes" failonerror="yes">
            <classpath refid="play.classpath"/>
            <jvmarg line="-javaagent:${play.path}/framework/play.jar -Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n"/>
            <sysproperty key="" value=""/>
            <sysproperty key="play.debug" value="true"/>
            <sysproperty key="application.path" value="${basedir}"/>
For the classpath I had the following:
    <path id="play.classpath">
        <pathelement path="${play.path}/framework/classes"/>
        <fileset dir="${play.path}/framework/lib">
            <include name="*.jar"/>
        <fileset dir="${play.path}/framework">
            <include name="*.jar"/>
        <fileset dir="lib" erroronmissingdir="false">
            <include name="*.jar"/>
        <!-- Add module libraries here!! -->

Since reading the module dependencies from the application.conf with Ant seemed bit difficult I ended up creating the Play antify module for the build.xml generation, very similar to the existing idealize or eclipsify commands.