Tech Beats

Here’s a simple filter I’ve been using to help me detect points of improvement in my application:

To use it, put this class in the grails-app/conf folder of your project. To activate the profile, call any URL of your application with the showTime=on parameter, like this:

http://localhost:8080/my-grails-app/book/list?showTime=on

After calling that URL, all request times will be measured and informed on the application’s log, like this:

2010-12-21 12:02:31,698 [http-8080-5] DEBUG filters.UtilFilters  - Request duration for (book/list): 20ms/50ms

The first time informed (20ms) is the time spent executing the action (list in this case) and the second (50ms) is the time spent rendering the view (list.gsp).

To turn off the profiler, call any URL with showTime=off:

http://localhost:8080/my-grails-app?showTime=on

Enjoy :)

Deluan.

UPDATE: This problem has been fixed in version 1.1.3 of the plugin. Thanks Marc and Luke Daley!

This week I tried the Marc Palmer’s excelent plugin Cache-Headers, and it really rocks! Using it I can make all my server-side generated images be cached on the client, reducing significantly the bandwidth and cpu-power necessary by my application.

But there’s a little gotcha: The plugin (as of version 1.1.2) uses a SimpleDateFormat to generate and check the Last-Modified header, and the implementation creates this SimpleDateFormat with the system’s default Locale, in my case Portuguese. This causes errors like this:

java.lang.IllegalArgumentException: Ter, 21 dez 2010 15:10:33 GMT
    at com.grailsrocks.cacheheaders.CacheHeadersService.withCacheHeaders(CacheHeadersService.groovy:140)
    at com.grailsrocks.cacheheaders.CacheHeadersService$withCacheHeaders.call(Unknown Source)
    at CacheHeadersGrailsPlugin$_addCacheMethods_closure7_closure11.doCall(CacheHeadersGrailsPlugin.groovy:61)
    at org.weceem.controllers.WcmContentController$_closure3.doCall(WcmContentController.groovy:172)
    at org.weceem.controllers.WcmContentController$_closure3.doCall(WcmContentController.groovy)
    at org.apache.shiro.web.servlet.ShiroFilter.executeChain(ShiroFilter.java:687)
    at org.apache.shiro.web.servlet.ShiroFilter.doFilterInternal(ShiroFilter.java:616)
    at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:81)

The workaround I found was to override the construction of that SimpleDateFormat. Luckily it’s been created in a small class, that is easy to extend:

All you have to do is put this class in your project (in the src/groovy folder) and add the following configuration override in your Config.groovy:

beans {
    cacheHeadersService {
        dateFormatters = new com.deluan.grails.util.EnglishDateFormatterThreadLocal()
    }
}

I already filled a bug report here: http://jira.codehaus.org/browse/GRAILSPLUGINS-2707, and probably this post will be obsolete in a near future :)

Deluan.

Apache Shiro is a powerful and easy-to-use Java security framework that performs authentication, authorization, cryptography, and session management. With Shiro’s easy-to-understand API, you can quickly and easily secure any application – from the smallest mobile applications to the largest web and enterprise applications.

Now that I decided to organize and publish some of my code/hacks here, I thought it would be a good thing to republish here my Grails caller script.

I work and mantain various Grails projects at the same time, and some of them uses versions of Grails as old as 1.0.3! So the question is: How to call the right version of grails command for a given project, the version that the project was created with?

First I tried changing the GRAILS_HOME environment variable every time I was going to work with a project that uses a different version than the default. But it’s just too much work for a thing that should be transparent. So I decided to create a shell script to solve this problem. The script should detect which Grails version to call when it’s executed. Here’s the script I came up with:

How it Works?

The script first checks if you specified a version in the command line, like: grails 1.3.5-SNAPSHOT create-app. If not, it looks for an application.properties file in the current folder. This file keeps some metadata for Grails' projects, including the Grails version the project was created with. If it does not find any application.properties in the current folder, it then just calls the default Grails installed in your system, the one that GRAILS_HOME points to.

Prerequisites

• All your Grails versions must be installed under the same base directory. Ex:

  /opt/grails-1.0.3
    /opt/grails-1.1.1
    /opt/grails-1.2-M2
    /opt/grails-1.3.3
    /opt/grails-1.3.5-SNAPSHOT

• GRAILS_HOME environment variable must be set and point to your “default” Grails installation

• This script was tested on Mac OS X (Snow Leopard), Linux (Ubuntu) and Windows (with cygwin)

Installation

• Download the script: http://gist.github.com/601039
• Include the folder where it is installed in your PATH.
• Exclude $GRAILS_HOME/bin from your PATH

Usage

Using the script is as transparent as possible:

• If you invoke it from a project folder, it will detect the version used by the project and call the correct grails (if it is installed in your system)
• If you invoke it from any other folder that does not contain a Grails project, it will call the “default” Grails installation

• If you want to call a specific Grails version (i.e. when doing an upgrade) you can specify the version you want in the first parameter. Ex:

  $ grails 1.3.3 upgrade

If you have any question or suggestion, please leave a comment here or send it to the Grails user list.

In a recent Grails project, I had to follow some corporate guidelines regarding application deployment, and one of those were that the log4j configuration for the application must be externalized and in the properties format.

I searched for a Grails plugin that could help me on this, with no luck. Then I remembered that a Grails application is just a Spring application in disguise, so I looked for the Spring way to do this.

There are at least two ways to do this using Spring: Log4jConfigListener and Log4jConfigurer. I choose the later because the former assumes an expanded WAR file, which was not my case.

Here’s the recipe I came up with:

• Configure a Log4jConfigurer Spring bean in your grails-app/conf/resources.groovy: (see here for a resources.xml version)

• Install the templates in your project with grails install-templates, so you can change some files used for Grails' code generation. The one we are interested is the web.xml template

• Comment out the Grails' Log4jConfigListener from the src/templates/war/web.xml template:

• You can (and should) remove the log4j configuration block from your Config.groovy

• That’s it!

This was tested with Grails 1.3.3, deploying to an Oracle WebLogic 10.3.0 container.

I've been working with Grails for some time now and if I had to choose just one good thing to say about it is how it's community is really great!

I think it's time to start giving back some contribution, and here's the first one: A Permalink Codec to generate permalinks based on strings. It strips out all non word chars and convert the resulting string to lowercase:

To use it in your Grails project, save it in `grails-app/utils/com/deluan/grails/codecs` folder as `PermalinkCodec.groovy`.

Please read the (excelent) Grails' manual for more info on how to use codecs.