Componentix blog

Quite often it is needed to execute Groovy script within a Grails application context (including access to domain objects, controllers, services, etc). Unfortunately there is no such built-in functionality in Grails.

However Ted Naleid has written run-script Gant script to do this and published on his blog.

We used it in our project and it worked flawlessly. However it stopped working with upgrade to Grails 1.3.1 and even grabbing the latest version from bitbucket haven’t helped.

So I looked into the sources of built-in Grails scripts, including run-test and hacked run-script a little bit to make it run fine.

You can grab/fork the resulting script on github.

Also, please vote for inclusion of run-script functionality into main Grails distribution in JIRA

Using the script is easy. Just store it in src/scripts/ folder of your Grails app with RunScript.groovy filename.

Then you’ll be able to run your scripts as following:

grails run-script path/to/script1/Script1.groovy path/to/script2/Script2.groovy ...

The script itself is:

import org.codehaus.groovy.grails.commons.GrailsClassUtils as GCU
import org.springframework.orm.hibernate3.SessionFactoryUtils
import org.springframework.orm.hibernate3.SessionHolder
import org.springframework.transaction.support.TransactionSynchronizationManager

includeTargets << grailsScript("_GrailsBootstrap")
includeTargets << grailsScript("_GrailsRun")
includeTargets << grailsScript("_GrailsSettings")
includeTargets << grailsScript("_GrailsClean")

target('default': "Execute the specified script after starting up the application environment") {
    depends(checkVersion, configureProxy, packageApp, classpath)
    runScript()
}

target(runScript: "Main implementation that executes the specified script after starting up the application environment") {
    parseArguments()
    if (argsMap["params"].size() == 0) {
        event("StatusError", ["Required script name parameter is missing"])
        System.exit 1
    }
    compile()
    loadApp()
    configureApp()
    configureHibernateSession()
    argsMap["params"].each { scriptFile ->
        executeScript(scriptFile, classLoader)
    }
}

def configureHibernateSession() {
    // without this you'll get a lazy initialization exception when using a many-to-many relationship
    def sessionFactory = appCtx.getBean("sessionFactory")
    def session = SessionFactoryUtils.getSession(sessionFactory, true)
    TransactionSynchronizationManager.bindResource(sessionFactory, new SessionHolder(session))
}

def executeScript(scriptFile, classLoader) {
    File script = new File(scriptFile)
    if (script.exists()) {
        def shell = new GroovyShell(classLoader, new Binding(ctx: appCtx, grailsApplication: grailsApp))
        shell.evaluate(script.text)
    } else {
        event("StatusError", ["Designated script doesn't exist: $scriptFile"])
    }
}
 

While testing some of the classes in Grails app, I had problem that the tests failed because Grails config (ConfigurationHolder.config) isn’t populated (is null) when unit tests are executed. Some Googling found me issue in JIRA which explained it.

Graeme Rocher commented that there is mockConfig method which allows to specify mocked config to be used for tests. It can be called in setUp method to do necessary initialization.

It is convenient to use it with multi-line strings. Its usage goes as following:

mockConfig '''
    foo.bar = "good"
'''

It is discussed in more details in mrhaki's post.

In one of our Grails applications we had to run a number of batch jobs. Nothing unusual and Grails supports it quite well with the excellent Quartz plugin.

But when we deployed application in production, we noticed that after running for some time, it consumed a lot of memory and JVM was spending all the time running garbage collection. The reason for it was that our jobs were quite long-running, taking several hours to complete, and Grails wasn’t really designed for such kind of use case.

First problem is actually well-known and documented — using single Hibernate session for a long time gets a lot of objects being added to cache. It is described for example in this blog post.
This basically goes into flushing and clearing Hibernate session like following:

sessionFactory.currentSession.flush() 
sessionFactory.currentSession.clear()

But while less memory was being leaked after that, the problem still wasn’t resolved. However thankfully to this nice post about Grails memory leak I learned about another more obscure problem and got it fixed.

Main idea is that save() method stores validation errors info in thread-local storage when HttpServletRequest instance is not available. So this info needs to be cleared from time to time, which can be achieved by something like this:

DomainClassGrailsPlugin.PROPERTY_INSTANCE_MAP.get().clear()

Resolving these two issues solved our problem with memory usage. Hopefully this post prevents you from spending much time resolving the same issues.

Recently found a really nice Grails plugin – Nimble.

It provides a complete solution for user profiles management, flexible authentication (both local and using OpenID) and fine-grained access control. It is based on Apache Shiro, which we used previously for authentication/access control.

I will try to use it in some simple project and then write a blog post describing my experience.

Offtopic: This is verification code for Technorati – QAEYYR9THPUN

In one of our Grails projects we had to use Microsoft SQL Server as a database. Hibernate has support for it and works good enough, however the schema generated by it is not ideal, at least from our point of view. In particular, properties of boolean type were stored in columns of type INT, while both SQL Server 2000 and 2005 support special type just for booleans — BIT; all Ids, which usually have type long, had to be squeezed into columns of type INT (again this stupid integer!); such SQL types as TEXT and IMAGE were used, instead of (preferred for SQL Server) VARCHAR(max) and VARBINARY(max) respectively; and finally (for me — the most annoying thing) strings were stored in non-Unicode sequences. The very last point is also very unhandy, since strings in Java are stored in Unicode, and having to deal with encodings explicitly when storing or reading strings or entire texts from the database is a bit against the simplicity we expect from Hibernate when we use it.

So I decided to develop customized Hibernate dialect for MS SQL Server. To do this, I started digging the source code of Hibernate (the dialect classes to be precise), and soon I found out that Hibernate’s SQLServerDialect extends from SybaseDialect, which is responsible for most of the “sins” outlined in the paragraph above. Don’t know why they haven’t overridden any of that in a subclass, probably they had a good reason not to do so, but for our company this reasoning was certainly not working out. Just extending the standard implementation was fairly enough to solve the problem, actually it was sufficient just to register appropriate column types in the constructor. The end result looks like this:

public class SQLServerDialect extends org.hibernate.dialect.SQLServerDialect {
 
   /**
    * Initializes a new instance of the {@link SQLServerDialect} class.
    */
    public SQLServerDialect() {
        registerColumnType(Types.BIGINT, "bigint");
        registerColumnType(Types.BIT, "bit");
        registerColumnType(Types.CHAR, "nchar(1)");
        registerColumnType(Types.VARCHAR, 4000, "nvarchar($l)");
        registerColumnType(Types.VARCHAR, "nvarchar(max)");
        registerColumnType(Types.VARBINARY, 4000, "varbinary($1)");
        registerColumnType(Types.VARBINARY, "varbinary(max)");
        registerColumnType(Types.BLOB, "varbinary(max)");
        registerColumnType(Types.CLOB, "nvarchar(max)");
    }
}

Obviously, similar technique can be used with any custom Hibernate dialect, not just for MS SQL. Feel free to use it with any other DB engine, etc. If you find it useful, you can fork our code snippet at Github: http://gist.github.com/225543

Recently we have got strange error in one of our projects when we upgraded it from Grails 1.2 M2 to Grails 1.2 M4.
After we did the upgrade we started getting java.lang.MissingMethodException for the domain class method calls.

Then it was determined by playing with grails console that the problem was limited to a single domain class. The source code file for it (say, MyDomainClass.groovy) looked like this:

class MyUtilityClass {
      // Some code here
}

class MyDomainClass {
      // Some code here
}

Well, it may be not the best idea to have two classes in the same source file, but that is a different question. Interesting thing is that it for some reason prevented Grails from adding the methods to MyDomainClass. And to resolve this issue very simple thing can be done — MyUtilityClass can be put in source file after MyDomainClass. That resolved problem for us.

Hopefully this post would be useful to someone with similar problem.

Introduction

For many developers Java is often a synonym for totally non-sexy enterprise applications development. It is associated with numerous XML configuration files, boilerplate code, etc. So they instead use dynamic languages like Ruby, Python, PHP to develop their projects, especially when these are own simple utilities, mash-ups, etc.

However the Java field has changed much in the recent few years. There are multiple frameworks which relieve developer from “enterprise” burden. Grails is probably one of the best. It is based on Groovy, which is a dynamic language running on Java platform designed specially for Java programmers. It uses well known robust and efficient Java libraries to do all the heavy lifting (Spring, Hibernate, etc.). There is also a plugin system and plugins exist for almost every widely used Java library.

In this article we’ll show how to make a mash-up of Twitter and Google Maps in around 20 minutes. The end result will look similar to this:

Finally we’ve launched our own blog. We’ll try to write interesting things about Java, Grails, iPhone or about anything else related to our work.

BTW, this blog is powered by Grails, same as other parts of our website.