After working with play a bit more I ran into an issue with the flash parameters. If you validate some input form, and there are errors, you can store the previously filled parameters in the flash scope. After that you can re-populate the content of the form again with the flash parameters. However if you have a selection with a lookup table, this will most of the times fail.
Here is a bit of code to explain this situation in more detail. In the html there is a list of entities available:
<select name="orderline.id" id="orderline_id">
<option value="">Select one
#{list items: orderlines, as: 'orderline'}
<option value='${orderline.id}' #{if flash['orderline.id'] != null && flash['orderline.id'] == orderline.id}selected="selected">${orderline.name}
#{/list}
</select>
If there is an error the system will select the previously selected orderline by comparing the orderline’s id with the one stored in the flash. However all of ther orderitem’s id’s are all of type long and the flash parameter is of type string, so this will never be equal.
With some mishandling of the default java extensions this can be avoided. Just grap a method of the java extensions that will not interfer with the type of long and return a string. For instance the method addSlashes(). This will replace all singel slashes with double slashes and return a string. But it will start by casting the object to a string, so this is almost what we want. Since the long will never have slashes this can be put to good use. It is a bit of a hack, but it works. Thus the code will be:
<select name="orderline.id" id="orderline_id">
<option value="">Select one
#{list items: orderlines, as: 'orderline'}
<option value='${orderline.id}' #{if flash['orderline.id'] != null && flash['orderline.id'] == orderline.id.addSlashes()}selected="selected">${orderline.name}
#{/list}
</select>
The better way would be of course, to create your own java extension, for instance a compare method, but for the time being the hack works.