In my current project we have a need to generate a set of files for each environment, using templates. As this is a Gradle project, this requirement is easily accomplished with a CopyTask:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

task processTemplates(type: Copy) {
     from 'src/templates', {
         include '**/*.*'
     }

     def env = loadEnvironment()
     eachFile { FileCopyDetails file ->
         if (file.name.endsWith('.template')) {
             expand(env)
             file.name = file.sourceName - '.template'
         }
     }

     inputs.file "env/${envName}.properties"
     into "$buildDir/output/$envName"
}

def getEnvName() {
    hasProperty('env') ? env : 'dev'
}

def loadEnvironment() {
    def properties = new Properties()
    new File("env/${envName}.properties").withInputStream { properties.load(it) }
    properties
}

The processTemplates task above will copy all files from src/templates to build/output/<envName>. All files whose name ends with .template will be processed and tokens (ex: ${variable}) will be replaced by their values from the env/<envName>.properties file. Adding the properties file as an input for the task is important (inputs.file method call), so when you change it, the task will be re-executed on the next build.

Simple, right?

Not so fast, Johnny…

This worked fine until we had one template that was really big (120KB) and we found out about issue GRADLE-3122. Gradle uses Groovy’s SimpleTemplateEngine, that can only process files up to 64KB!

Newest versions of Groovy (2.4+) include StreamingTemplateEngine that does not have this limit, but the most recent version of Gradle (2.5 as of this post) still uses Groovy 2.3…

One way to overcome this would be to use Ant’s ReplaceTokens filter, simply by changing our templates to use Ant’s token syntax (ex: @variable@) and changing the line expand(env) to filter(ReplaceTokens, tokens: env)

But because we need to use logic in our templates (if’s and loops), we had to come up with a different approach. The solutions available were too simple for our needs or too complicated to implement in a clear way, making them unsuitable for our project. So we decided to roll…

Our own solution

Finally we decided to implement a simple template processor using FreeMarker. We select this awesome template engine for its feature set, IDE support and excelent OSS reputation, although the solution bellow could be adapted to be used with any other template engine (Velocity, JMustache, etc…)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58

package your.package

import freemarker.template.Configuration
import org.apache.commons.io.FileUtils
import org.apache.tools.ant.DirectoryScanner

import static freemarker.template.TemplateExceptionHandler.RETHROW_HANDLER

class TemplateProcessor {
    private static final String TEMPLATE_EXTENSION = '.ftl'
    private String templatesDir
    private String outputDir
    private Configuration cfg

    TemplateProcessor(String templatesDir, String outputDir) {
        this.templatesDir = templatesDir
        this.outputDir = outputDir

        cfg = new Configuration()
        cfg.setDirectoryForTemplateLoading(new File(templatesDir))
        cfg.setDefaultEncoding("UTF-8")
        cfg.setTemplateExceptionHandler(RETHROW_HANDLER)
    }

    void execute(Map properties) {
        DirectoryScanner scanner = createScanner()
        scanner.scan()
        scanner.includedFiles.each { String fileName ->
            if (fileName.endsWith(TEMPLATE_EXTENSION)) {
                process(fileName, properties)
            } else {
                copy(fileName)
            }
        }
    }

    private process(String fileName, Map properties) {
        def outputFile = new File(outputDir, fileName - TEMPLATE_EXTENSION)
        def template = cfg.getTemplate(fileName)

        outputFile.withWriter { out ->
            template.process(properties, out)
        }
    }

    private copy(String fileName) {
        def inputFile = new File(templatesDir, fileName)
        def outputFile = new File(outputDir, fileName)
        FileUtils.copyFile(inputFile, outputFile)
    }

    private DirectoryScanner createScanner() {
        def scanner = new DirectoryScanner()
        scanner.includes = ['**/*']
        scanner.basedir = new File(templatesDir)
        scanner
    }
}

Note that we now use the .ftl file extension for our templates, to enable support in our IDE of choice. To use the processor, you have to put it under the buildSrc project. This is a special “module” in your project that is a simple way to organize build logic in your build scripts. It is all automatically handled by Gradle. You’ll also need a small build.gradle just for declaring the dependencies for FreeMarker and Apache Commons IO (used for the copyFile method):

1
2
3
4
5
6

repositories { mavenCentral() }

dependencies {
    compile 'org.freemarker:freemarker:2.3.23'
    compile 'commons-io:commons-io:2.4'
}

To have this code available to your main build script, add this two files in your project, in the following paths:

• buildSrc/build.gradle
• buildSrc/src/main/groovy/your/package/TemplateProcessor.groovy

The last step is to actually use it in our processTemplates task:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

import your.package.TemplateProcessor

task processTemplates() {
    def fromDir = 'src/templates'
    def intoDir = "$buildDir/output/$envName"
    doLast {
      def env = loadEnvironment()
      new TemplateProcessor(fromDir, intoDir).execute(env)
    }

    inputs.dir fromDir
    inputs.file "env/${envName}.properties"
    outputs.dir intoDir
}

Not hard, eh? Note that this task is not a CopyTask anymore, so we now need to specify its inputs and outputs.

My plan is to convert this code into a proper Gradle plugin. But for now: That’s all, folks!

The data should be: código redome;;código hemocentro;nome;nome da mãe;

The file was generated with Windows Excel, using the encoding ISO-8859-2 (common encoding for Windows). After some investigation I found out that Fileupload by default treats all files with content type text/... as UTF-8! Ouch!!

If all your files will be generated using the same file encoding, this can be fixed with the following configuration:

1
2
3
4
5
6
7

<zk>
  <system-config>
    <upload-charset>YOUR ENCODING</upload-charset> <!-- ISO-8859-2 in my case -->
    ...
  </system-config>
  ...
</zk>

The upload-charset tag did the trick! But what if my user decides to move to a different (better?) platform in the future, and generates the file with UTF-8? Or any other encoding?

Then the proper solution is to use the tag upload-charset-finder-class:

1

<upload-charset-finder-class>a_class_name</upload-charset-finder-class>

The documentation says that this class has to implement the interface CharsetFinder and its sole method String getCharset(String contentType, InputStream content):

When a text file is uploaded, the getCharset method is called and it can determines the encoding based on the content type and/or the content of the uploaded file.

Which leads us to the main reason of this post: How to detect the file encoding, if ZK itself does not provide a default implementation for this interface?

More research pointed me to some solutions, but the one that I ended up implementing was using the Apache Any23. It includes the TikaEncodingDetector, that can be used to auto-detect the file encoding of a stream. The final code for the CharsetFinder implementation is the following:

1
2
3
4
5
6
7
8
9
10
11
12
13

package util;

import org.apache.any23.encoding.TikaEncodingDetector;
import org.zkoss.zk.ui.util.CharsetFinder;

import java.nio.charset.Charset;

public class TikaCharsetFinder implements CharsetFinder {
    @Override
    public String getCharset(String contentType, InputStream content) throws IOException {
        return new TikaEncodingDetector().guessEncoding(content);
    }
}

Yep, it is that simple. The final ZK configuration to use this class is:

1
2
3
4
5
6
7

<zk>
  <system-config>
    <upload-charset-finder-class>util.TikaCharsetFinder</upload-charset-finder-class>
    ...
  </system-config>
  ...
</zk>

class UtilFilters {

    def filters = {

        profiler(controller: '*', action: '*') {
            before = {
                request._timeBeforeRequest = System.currentTimeMillis()
            }

            after = {
                request._timeAfterRequest = System.currentTimeMillis()
            }

            afterView = {
                if (params.showTime) {
                    session._showTime = params.showTime == "on"
                }
                if (session._showTime) {
                    def actionDuration = request._timeAfterRequest - request._timeBeforeRequest
                    def viewDuration = System.currentTimeMillis() - request._timeAfterRequest
                    log.debug("Request duration for (${controllerName}/${actionName}): ${actionDuration}ms/${viewDuration}ms")
                }
            }
        }
    }

}

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:

1

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:

1

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:

1

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

Enjoy :)

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:

1
2
3
4
5
6
7
8
9

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:

package com.deluan.grails.util

import java.text.SimpleDateFormat
import com.grailsrocks.cacheheaders.DateFormatterThreadLocal

/**
 * This class is used to force CacheHeadersService (from the cache-headers 
 * plugin) to generate http-dates in english. It MUST be used when the 
 * locale of your server is not English.
 * <p/>
 * To use it, put the following configuration in your Config.groovy:
 * <pre>
 * beans {
 *    cacheHeadersService {
 *        dateFormatters = new com.deluan.grails.util.EnglishDateFormatterThreadLocal()
 *    }
 * }
 * </pre>
 * 
 * @author Deluan
 */
class EnglishDateFormatterThreadLocal extends DateFormatterThreadLocal {
    SimpleDateFormat initialValue() {
        def v = new SimpleDateFormat(RFC1123_DATE_FORMAT, Locale.ENGLISH)
        v.timeZone = TimeZone.getTimeZone('GMT')
        return v
    }
}

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:

1
2
3
4
5

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 :)

First, a small introduction. You can skip it and go straight to the source code, if you want.

I started working with Apache Shiro when it was still called JSecurity, and I have to say that it really rocks! I tried to use Spring Security (Acegi) in some projects, but the easiness and lean approach of Shiro is unbeatable. For a quick introduction, here’s a quote from the project’s site:

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.

I’ve used it in Java and Grails projects, and recently I’ve even been experimenting it with Google App Engine. It fits very well in almost any Java platform project that needs security.

Shiro already works great in a JSF/Facelets project. You can use its filters to grant and deny access to some parts of your application and to force authentication (redirect to login).

The only functionality missing is the power of its JSP taglib, that is used to conditionally render some parts of your HTML, based on user’s authorization, roles and permissions (you can learn how to use them with this simple example project). The problem is that this conditional rendering is not totally compatible with JSF’s phases. Better than trying to fit a cube into a spherical hole, I decided to rewrite Shiro’s JSP tags into a Facelets taglib, totally compatible with JSF.

All original tags are available as their Facelets equivalents, and I have introduced two new ones:

<shiro:hasAnyPermission> - Displays body content only if the current user has one of the specified permissions from a comma-separated list of permission strings.

<shiro:remembered> - Displays body content only if the current user has a known identity that has been obtained from ‘RememberMe’ services. Note that this is semantically different from the <shiro:authenticated> tag, which is more restrictive.

I’ve already submitted a patch to Shiro’s development team, but they’re very busy at the moment packaging the new 1.1 version for release. So I decided to share the taglib on GitHub, and host the artifacts in my personal maven repository, as I need to use the tags in an on-going project.

If you want to try it in your maven project, add my repository to your pom.xml:

        <repositories>
                <repository>
                    <snapshots>
                        <enabled>false</enabled>
                    </snapshots>
                    <id>bintray-deluan-maven</id>
                    <name>bintray</name>
                    <url>http://dl.bintray.com/deluan/maven</url>
                </repository>
        </repositories>

and add the jar dependency:

        <dependency>
            <groupId>org.apache.shiro</groupId>
            <artifactId>shiro-faces</artifactId>
            <!-- See the latest version on the project's homepage -->
            <version>2.0</version>
        </dependency>

Now you can declare Shiro’s namespace in your xhtml pages and use the tags like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"
      xmlns:ui="http://java.sun.com/jsf/facelets"
      xmlns:shiro="http://shiro.apache.org/tags">
<head>
    <title><ui:insert name="titulo">Shiro Faces Test</ui:insert></title>
</head>

<body>
    <p>Hi, <shiro:guest>Guest</shiro:guest>
          <shiro:user><shiro:principal/></shiro:user>!
    </p>
</body>

</html>

That’s it! Just keep in mind that as soon as this lib gets incorporated officially in Shiro, I’ll stop updating it in GitHub and all future enhancements will only be available in the official version. If you want to see the tags incorporated officially into Shiro sooner than later, you can vote here: https://issues.apache.org/jira/browse/SHIRO-206

And if you have any suggestion, please let me know.

Enjoy ;)

Here’s a little tutorial on how to configure Spring in your Gaelyk project. I’m assuming you have basic knowledge of Spring, Gaelyk and Maven.

First, let’s create a Gaelyk project. The easiest way is using the excellent maven-gaelyk archetype:

1

mvn archetype:generate -DarchetypeGroupId=org.codeconsole -DarchetypeArtifactId=gaelyk-archetype -DarchetypeVersion=0.5.5 -DarchetypeRepository=http://maven-gaelyk.googlecode.com/svn/repository/ -DartifactId=gaelyk-spring -DgroupId=com.deluan.gaelyk -DgaeApplicationName=gaelyk-spring

Now open the project in your favorite IDE, so we can edit the configuration files. First, add the Spring dependency to your pom.xml:

        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-web</artifactId>
            <version>${spring.version}</version>
        </dependency>

Next we need to configure Spring’s ContextLoaderListener in web.xml:

    <context-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>
            /WEB-INF/spring/*.xml
        </param-value>
    </context-param>

    <listener>
        <listener-class>
            org.springframework.web.context.ContextLoaderListener
        </listener-class>
    </listener>

As you can see from above, we configured Spring to load all context configuration files under the directory WEB-INF/spring.

With these configurations in place, your project is already Spring enabled. Now we need a easy way to access the Spring’s Application Context. One good way to do this is using a singleton that implements the ApplicationContextAware interface. To keep this post as small as possible, I borrowed an implementation from this blog post, where you can learn more about the details. Create the directory src/main/groovy and put the following SpringApplicationContext singleton there (in the correct package):

package com.deluan.gaelyk;

import org.springframework.beans.BeansException;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ApplicationContextAware;

/**
 * Wrapper to always return a reference to the Spring Application Context from
 * within non-Spring enabled beans. Unlike Spring MVC's WebApplicationContextUtils
 * we do not need a reference to the Servlet context for this. All we need is
 * for this bean to be initialized during application startup.
 *
 * Original from http://sujitpal.blogspot.com/2007/03/accessing-spring-beans-from-legacy-code.html
 */
public class SpringApplicationContext implements ApplicationContextAware {

    private static ApplicationContext CONTEXT;

    /**
     * This method is called from within the ApplicationContext once it is
     * done starting up, it will stick a reference to itself into this bean.
     * @param context a reference to the ApplicationContext.
     */
    public void setApplicationContext(ApplicationContext context) throws BeansException {
        CONTEXT = context;
    }

    /**
     * This is about the same as context.getBean("beanName"), except it has its
     * own static handle to the Spring context, so calling this method statically
     * will give access to the beans by name in the Spring application context.
     * As in the context.getBean("beanName") call, the caller must cast to the
     * appropriate target class. If the bean does not exist, then a Runtime error
     * will be thrown.
     * @param beanName the name of the bean to get.
     * @return an Object reference to the named bean.
     */
    public static Object getBean(String beanName) {
        return CONTEXT.getBean(beanName);
    }

    public static ApplicationContext getContext() {
        return CONTEXT;
    }
}

Configure the singleton in your spring context:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">

    <bean id="springApplicationContext" class="com.deluan.gaelyk.SpringApplicationContext"/>

    <bean id="dateFormat" class="java.text.SimpleDateFormat">
        <constructor-arg value="yyyy/MM/dd" />
    </bean>

    <bean id="timeFormat" class="java.text.SimpleDateFormat">
        <constructor-arg value="hh:mm:ss" />
    </bean>

    <bean id="dateTimeFormat" class="java.text.SimpleDateFormat">
        <constructor-arg value="yyyy/MM/dd hh:mm:ss" />
    </bean>

</beans>

As you can see, I also declared some SimpleDateFormat instances as beans to be used in our examples.

Now everything is configured and ready to be used. Let’s see how we can obtain a spring bean inside a Groovlet. Create the file WEB-INF/groovy/index.groovy with the following content:

import com.deluan.gaelyk.SpringApplicationContext

def dateFormat = SpringApplicationContext.getBean('dateFormat')
def now = new Date()

println dateFormat.format(now)

Now run your application with the command mvn gae:run, point your browser to http://localhost:8080/index.groovy and you should see something like this:

Well, that’s it! Nothing much different from what you are used to do in a normal Web application, right? But remember: Gaelyk is NOT your normal Web framework so let’s spice things a little bit.

The solution for looking up beans depicted above is a bit cumbersome. Let’s use Gaelyk’s plugin system to make things a little more “groovy”. Using the plugin descriptor bellow, we can provide shortcuts to our SpringApplicationContext’s methods, getContext() and getBean(). Save it in the file WEB-INF/plugins/spring.groovy:

import com.deluan.gaelyk.SpringApplicationContext

binding {
    appCtx = SpringApplicationContext.context

    getBean = {
        SpringApplicationContext.getBean(it)
    }

    autowire = { self, beanNames ->
        beanNames.each {
            self.setProperty(it, SpringApplicationContext.getBean(it))
        }
    }
}

Before you can use these shortcuts, you need to tell Gaelyk about your descriptor by “installing” it in your project. Save the code bellow in the file WEB-INF/plugins.groovy:

install spring

Now you can use the shortcuts in your Groovlets this way:

def now = new Date()

// Simple context lookup
def dateFormat = getBean('dateFormat')

// Resolve a list of bean names and create bindings for each one of them
autowire this, ['timeFormat', 'dateTimeFormat']

html.html {
    body {
        p appCtx.displayName  // Access the ApplicationContext
        p dateFormat.format(now)
        p timeFormat.format(now)
        p dateTimeFormat.format(now)
    }
}

Cool, isn’t it? A note on the autowire binding: It creates bindings “automagically” for each bean you passed as a parameter, as if the beans were declared in your Groovlet.

You can download the sample project used in this post from GitHub: http://github.com/deluan/gaelyk-spring. You can follow each commit to see exactly what was changed in each step of this tutorial.

If you have any suggestion or question, please let me know.

UPDATE: I’ve refactored the autowiremethod into a Category, so now it’s not necessary to pass this as the first parameter. The new version is available at GitHub

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 on and maintain 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:

#!/bin/sh
# Author: Deluan (http://techbeats.deluan.com)

# Check if GRAILS_HOME is set
if [ -z "$GRAILS_HOME" -o ! -d "$GRAILS_HOME" ]; then
    echo "Error: GRAILS_HOME not set"
    exit 2
fi

# Extract the base path from GRAILS_HOME
BASE_GRAILS_PATH=`echo $GRAILS_HOME | sed -e "s/[^\/\\]*$//" -e "s/^$/./"`
APP_PROP="application.properties"

# Try to get the version from the command line
TRY_VERSION=$1
if [ -d "${BASE_GRAILS_PATH}/grails-${TRY_VERSION}" ]; then
    VERSION=$TRY_VERSION
    shift
fi 

# Or else get the version from the application.properties in the current directory
[ -z "$VERSION" -a -f "$APP_PROP" ] &&
    VERSION=`awk -F'=' '/app.grails.version/ { print $2 }' $APP_PROP | tr -d '\r\n'`

# Or else use the default version
if [ -z "$VERSION" ]; then  
    VERSION=`basename $GRAILS_HOME | cut -f 2 -d "-"`
fi

export GRAILS_HOME=${BASE_GRAILS_PATH}/grails-${VERSION}
GRAILS_CMD=${GRAILS_HOME}/bin/grails

if [ ! -x "$GRAILS_CMD" ]; then
    echo "Error: grails command not found at '$GRAILS_CMD'!"
    exit 3
fi

exec $GRAILS_CMD $*

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:

1
2
3
4
5

  /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://github.com/deluan/grails.sh/raw/master/grails
• 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:

1

$ grails 1.3.3 upgrade

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

There are at least two ways to do this using Spring: Log4jConfigListener and Log4jConfigurer. I chose 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: (click here for a xml version)

beans = {
    log4jConfigurer(org.springframework.beans.factory.config.MethodInvokingFactoryBean) {
        targetClass = "org.springframework.util.Log4jConfigurer"
        targetMethod = "initLogging"
        arguments = ["classpath:myapp/log4j.properties"]
    }

    ...

}

• 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 in is the web.xml template.

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

    <filter-mapping>
        <filter-name>sitemesh</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>


    <!-- Comment this out!
    <listener>
        <listener-class>org.codehaus.groovy.grails.web.util.Log4jConfigListener</listener-class>
    </listener>
    -->

    <listener>
        <listener-class>org.codehaus.groovy.grails.web.context.GrailsContextLoaderListener</listener-class>
    </listener>

• 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 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:

/*
 * Copyright 2010 Deluan Cotts (grails@deluan.com.br)
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *     http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

package com.deluan.grails.codecs

import java.util.regex.Matcher
import java.util.regex.Pattern

/**
 * Strip all non word chars, convert to lowercase
 */
class PermalinkCodec {
    private static final String[] CARACTERES_SEM_ACENTO
    private static final Pattern[] PATTERNS

    static {
        CARACTERES_SEM_ACENTO = ["a", "e", "i", "o", "u", "c", "n"]
        PATTERNS = new Pattern[CARACTERES_SEM_ACENTO.length]
        PATTERNS[0] = Pattern.compile("[áàãâä]", Pattern.CASE_INSENSITIVE)
        PATTERNS[1] = Pattern.compile("[éèêë]", Pattern.CASE_INSENSITIVE)
        PATTERNS[2] = Pattern.compile("[íìïî]", Pattern.CASE_INSENSITIVE)
        PATTERNS[3] = Pattern.compile("[óòöõô]", Pattern.CASE_INSENSITIVE)
        PATTERNS[4] = Pattern.compile("[úùüû]", Pattern.CASE_INSENSITIVE)
        PATTERNS[5] = Pattern.compile("ç", Pattern.CASE_INSENSITIVE)
        PATTERNS[6] = Pattern.compile("ñ", Pattern.CASE_INSENSITIVE)
    }

    private static String replaceSpecial(String text) {
        String result = text
        for (int i = 0; i < PATTERNS.length; i++) {
            Matcher matcher = PATTERNS[i].matcher(result)
            result = matcher.replaceAll(CARACTERES_SEM_ACENTO[i])
        }
        return result
    }

    static encode = {str ->
        str = replaceSpecial(str.toString().toLowerCase())
        return str.replaceAll("\\W", "-")
    }

}

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.