There are several things that cause application.properties to get re-written by Grails, the most common of which for me is installing / uninstalling plugins.  Since this is a properties file, the order of the lines is unimportant (they’re just key value pairs, after all), until your build machine does an ’svn up’ and encounters all sorts of conflicts that can’t be resolved automagically.

There are two (well, OK, three) ways to workaround this:

1. Tell hudson do to a clean checkout with each build.  To do this just make sure the “Use update” box is NOT checked under the subversion modules section of your build configuration.  This works well if your project is relatively small and you have a fast connection to your source code repository.
2. Revert the application.properties file before the build happens.
3. Stop using SVN.  Well, I don’t actually know if other SCMs handle this better, but it wouldn’t surprise me.  I certainly know of a few that handle it worse!

For the most part I’ve been using option #1 – until I recently added a very large project to the Hudson build…  The build time more than doubled – and that’s just unacceptable.

Enter Option #2.  In your build configuration, add an “Execute Shell” Build Step that happens BEFORE your Grails build that reverts the file so that the workspace always has the latest and greatest – without conflicts.

Note that depending on how your checkout works, you may need to add the checkout path in front of application.properties, for example:

svn revert yourGrailsApp/application.properties

If there’s a better way, I’d love to hear it.  In the mean time, this extra little build step works great!

The site also takes advantage of several other plugins, including

• Spring Security
• UI Performance
• Recaptcha
• Build Test Data
• Test Code Coverage (of course)

Thanks to all the plugin developers who took the time to build and document plugins for the Grails framework!

I also wrote one other plugin that wraps GreenMail and acts as a transient “Inbox” for sending emails during development. I’m putting the finishing touches on that now, stay tuned for more information.

Check it out and give it a try!

loggingSql=true

This will show you the prepared statement that Hibernate is generating, like this:

SELECT
        this_.id AS id6_0_,
        this_.version AS version6_0_,
        this_.authority AS authority6_0_,
        this_.description AS descript4_6_0_
    FROM
        role this_
    WHERE
        this_.authority=?

This is a good first step – but what if I want to see the parameter that is being sent as well?  You could turn logging for the org.hibernate.type package to TRACE level:

//in Config.groovy
log4j = {
    trace  'org.hibernate.type'
}

YIKES! That gets REALLY noisy, really fast:

Hibernate:
    select
        this_.id as id6_0_,
        this_.version as version6_0_,
        this_.authority as authority6_0_,
        this_.description as descript4_6_0_
    from
        role this_
    where
        this_.authority=?
TRACE type.StringType  - binding 'ROLE_USER' to parameter: 1
TRACE type.LongType  - returning '1' as column: id6_0_
TRACE type.LongType  - returning '1' as column: version6_0_
TRACE type.StringType  - returning 'ROLE_USER' as column: authority6_0_
TRACE type.StringType  - returning 'Default user role' as column: descript4_6_0_

Besides, what I really want is the ability to copy and paste a query, with the parameters bound, directly into a SQL editor to execute the query and see the results myself. Enter the p6spy plugin for Grails:

grails install-plugin p6spy

Swap the driver in your DataSource.groovy file from your driver to the p6spy driver (the plugin will automatically add this, you just need to comment it in):

environments {
  development {
    dataSource {
      //driverClassName = "org.hsqldb.jdbcDriver"
      driverClassName = "com.p6spy.engine.spy.P6SpyDriver"
    }
  }
}

Fire up your Grails application – p6spy will create a spy.log file in your application directory and log a pipe delimited line – the last column has the actual SQL being executed, with the parameters!

select this_.id as id2_0_, this_.version as version2_0_, this_.authority as authority2_0_, this_.description as descript4_2_0_ from role this_ where this_.authority='ROLE_USER'

This is a great start, and most people stop here. But sometimes there are so many queries being executed that it’s difficult to wade through spy.log to find the one you’re looking for. Thanks to a tip from the excellent Grails In Action book that was recently released – SQL Profiler can help!

Download SQL Profiler (http://sourceforge.net/projects/sqlprofiler) and add these lines to grails-app/conf/spy.properties:

log4j.appender.SQLPROFILER_CLIENT=org.apache.log4j.net.SocketAppender
log4j.appender.SQLPROFILER_CLIENT.RemoteHost=localhost
log4j.appender.SQLPROFILER_CLIENT.Port=4445
log4j.appender.SQLPROFILER_CLIENT.LocationInfo=true

Add the appender to the logger definition:

log4j.logger.p6spy=INFO,STDOUT,SQLPROFILER_CLIENT

Finally, make sure the Log4j Appender is enabled:

#specifies the appender to use for logging
appender=com.p6spy.engine.logging.appender.Log4jLogger
#appender=com.p6spy.engine.logging.appender.StdoutLogger
#appender=com.p6spy.engine.logging.appender.FileLogger

Then, in the directory in which you downloaded the SQL Profiler jar, launch the GUI with this line:

java -jar sqlprofiler.jar

Now, p6spy will log SQL to the SQL Profiler GUI! You can use it to profile SQL statements, but you can also use the ‘Logger’ tab to filter the log. I click the little trash can icon in the upper left to clear the log, run a test in the application, then filter the results using the filter fields available. For instance, if I only want to see queries related to the ‘ROLE’ table, just put the word ‘role’ in the Filter message text box, and you’ll only see queries related to that table. It’s a great way to get straight at a particular SQL query when you’re drowning in tons and tons of SQL messages.