Logging database content changes in a Play Framework app

To do this we use Hibernate Envers.

There are 3 easy steps to adding change logging to the data in your existing Play Framework app (I am using 1.2.4 – version 2 may well be different):

  1. Add the library
  2. Add the standard configuration
  3. Add an annotation to each class where you want to track data changes

Add the library in conf/dependencies.yml

    - play
    - play -> crud
    - org.hibernate -> hibernate-envers 3.6.1.Final:
            - org.hibernate -> hibernate-tools 3.2.0.ga
            - org.beanshell -> bsh 2.0b4
            - freemarker -> freemarker 2.3.8
            - org.hibernate -> jtidy r8-20060801
            - ant -> ant 1.6.5

Add the Envers configuration to conf/application.conf

# Hibernate Envers Auditing Library conf

Add an annotation to each class you want to audit

import org.hibernate.envers.Audited;

public class Book extends Model {
  public String title;
  public String author;
  public String description;

If you run up your app and make a change to an entity you will see a new table appear in your database. If your entity table is BOOK your new table will be BOOK_AUD. It contains a version reference (a normalised reference to a new revinfo table containing the timestamp of that audit entry) and the values of all the fields on the entity after the changes were saved.

You can go wild on the config by auditing only particular fields on an entity (just add @Audited to those fields), or adding new fields to the audit log (like who made the change or what method was called to do it), and change the name of table suffix.

It’s also quite simple to retrieve the list of versions, and this has been written up quite clearly by Matthieu Guillermin (it’s in French but Google Translate does a good job, and you can read the code anyway).

All of this information had already been written in several places, but hopefully this has brought it together in a useful way.

My config changes are from https://gist.github.com/1148850 and https://gist.github.com/1148852 by Marc Deschamps.

Setting up the Play framework on Google App Engine

The Play framework is the most fun I’ve had developing Java web applications. It’s fast, natural, comes with a rails-like scaffolding for CRUD operations on your model, has built-in Selenium testing as well as unit and functional tests, and most importantly Just Works.

It also deploys natively onto Google App Engine, but this isn’t described very well in the official documentation so here are the basics:

Get started

  1. Get yourself a GAE account and set up an application. you will need the ID.
  2. Download a recent nightly of the stable 1.0 branch (1.0 final doesn’t work with GAE, and Play needs to sort out its versioning system here)
  3. Unzip
  4. Download the GAE SDK for Java
  5. Unzip
  6. Create your app (although use Siena rather than JPA if you want to persist to the GAE data store) and configure it to use the GAE module
  7. Add your GAE application ID to myapp/war/WEB-INF/appengine-web.xml

Deploy to a local dev GAE environment

  1. run play war myappname -o myappname-war
  2. run APPENGINE_SDK_DIR/bin/dev_appserver myappname-war

Deploy to the GAE server

  1. run play war myappname -o ../myappname-war
  2. run APPENGINE_SDK_DIR/bin/appcfg update myappname-war/
  3. log in to your app engine console and check out your application!

Java makes me passionate


I really like Java, it’s a fundamentally great language. Verbose at times, but great.

However, web application development in Java is painful. Additionally, the compilation and deployment of Java webapps completely suck. I mean, they’re terrible.

I dread to think how many frameworks exist in Java to ease web app development – each one claiming it’s the best and will solve all your woes, yet none come anywhere close to the ease of development in Rails, Django, or any of the PHP frameworks.

I remember being introduced to JSF at ApacheCon Europe 2006. I came back declaring that we would never use JSF for our internally-developed applications. When there was masses of hype, and everyone was claiming JSF was amazing, I got a few questions in the office.

Two years on and there’s finally some acceptance that JSF 1.0 was horrible for developing web applications, with some defensively claiming that JSF 2.0 will solve all the problems. Right, because that always works.

See the recent discussion:

Anyway this means I try and keep a close eye on things like JRuby and Grails but we’ve been pretty reluctant to use them at work because we tend to have large monolithic applications which require maintenance by different people over time which means code homogenisation is good.

To this end, our last couple of projects have been in Struts2+Spring+JPA+Hibernate. This is a nice combination, with a number of well-understood components working well together, especially since we’ve used the Zero Configuration plugin which allows us to drop tens of lines of XML in favour of a few lines of annotations. The Zero Configuration stuff is as buggy as hell and there’s no concrete date for Struts 2.1.2 where it should be fixed, but that’s by-the-by. For me, the fact that we haven’t had to be editing XML almost makes it worth it 😉 Also, Struts2 is highly testable which fits in nicely with our existing testing process.

But when you have a framework you’re (mostly) happy with for development, it highlights the other pain points you may have. For us, this was definitely the deploy/test cycle. We were already using TDD in the compile cycle so there’s a level of confidence about the backend code – tests always run after a successful compile, but when you’re amending the web interface either for small cosmetic changes or for larger changes of data representation there’s a long recompile, redploy, retest cycle that drives me insane. Obviously there are ways around it if you’re using something like Eclipse and have a web application in the structure it needs but we tend to have a number of files which are built at compile-time by Ant. Also, I don’t like being tied to an IDE for tooling purposes – I’m very happy with my current editor thank you very much. The only real missed opportunity was AppFuse – we remembered about it too late; any other Struts2 projects will probably start with it though.

All of this is why I was pleased to see Play! . It’s a just-in-time compilation framework where the controllers and model are pure Java and the view is Groovy; excellent!

This means that we can reduce the time taken to learn (we only need to learn one component – the view – plus config) whilst leaving all the business logic in a state maintainable by anyone in the team. It serves up locally through Apache Mina whilst also being deployable to a more conventional container like Tomcat or JBoss. Changes to both business logic and template are instant, and you can still test it to your heart’s content !

Unfortunately the latest stable version (1.0-stable3 at writing) doesn’t contain critical features like, um, if..else in the template language. Everything seems to be in the nightly, but having been burned with the Zero Configuration Struts plugin (which had the notice “This is experimental. Feedback is appreciated!”) I wouldn’t like to commit any real effort to writing an application in it. As soon as they have that core stuff nailed down though – I’m there.