mor.ph and deployment fun

So I use http://mor.ph for deployment of my Grails applications. The development account was great, fantastic to deploy to and try out your application. I didn't realize this transformed (database and all) into your deployed site otherwise I would have held it in dev mode until the customer had set up all their data, but then I wouldn't have discovered some other problems... Like that since you get two app servers, and it load balances, it serializes session state (how often, I don't know). But as I use the Acegi plugin for Grails, it generally (definately in my case) creates a User object - which isn't serialized..... Which means I have been getting persistence errors all through my logs.

Of course, I thought I had solved it with just User and Role, but I forgot I embedded an Address in there as well, and it would need the treatment. Wouldn't it be great if these sites gave you a bundle you could run in a VM on your own machine to mimic their deployment so you could fix your issues before you swap from single server, single db to the full cluster of mor.ph? Oh well, it is a great service in any case!

groovy tip #3534

Don't do integer arithmetic in gstrings.

int time = 1730
println "${time/100}"

I know Mars Edit is going to screw up that code block. Anyway, although time is an int, it gets converted to a BigDecimal in the gstring, and you get a 17.3 instead of the expected 17.

And last but not least, our first Illegal Argument podcast has gone out. It hasn't shown up on iTunes yet, hopefully that will be soon.

Site Mesh and pageProperty in Grails

So Grails 1.1 comes with SiteMesh 2.4 and uses the FastPageParser. If you go have a look in your web-app/WEB-INF/sitemesh.xml file you will see the following:

<sitemesh>
    <page-parsers>
        <parser content-type="text/html" class="com.opensymphony.module.sitemesh.parser.FastPageParser" />
        <parser content-type="text/html;charset=ISO-8859-1"             class="com.opensymphony.module.sitemesh.parser.FastPageParser" />
        <parser content-type="text/html;charset=UTF-8"            class="com.opensymphony.module.sitemesh.parser.FastPageParser" />
        </page-parsers>
    <decorator-mappers>
        <mapper class="org.codehaus.groovy.grails.web.sitemesh.GrailsLayoutDecoratorMapper" />
    </decorator-mappers>
</sitemesh>

How many of you Grails developers have ever had to look in there? Cool isn't it that Grails shields you from this stuff - one of the many, many reasons why I love this framework.

Unfortunately, FastPageParser is actually deprecated and has bugs when using the <content tag="x"> constructs - HTML comments are output as raw text and <script> tags loose their <. Migrating to Site Mesh 2.4.1 (or .2 now with the GAE) fixes the <script> problem, but not the HTML problem.The partial solution (as emailed to me by one James) is to replace it with the HTTPPageParser - this is faster (by about twice) and is the recommended replacement for FastPageParser.

The only problem is that it has an outstanding bug - if you include an "<" anywhere in an HTML element (e.g. in the value) then the rendering goes haywire. It is a known fault in Site Mesh but no-one bothered to create a test case for Joe or investigate precisely where the problem is. Content tags are pretty important to anyone laying out their content in any kind of sophisticated manner (as is extractProperty, which isn't actually surfaced in Grails for some weird reason), so I gave Joe the test case and narrowed it down to the Lex rules. Unfortunately, I am not a Lex guru, so I had to leave it there.

I'll be putting up a screen cast of this stuff at some point in the near future. I'll link when its available.