Problem with Grails Integration Test in IntelliJ IDEA

I tried to test a Grails Service with an Integration Test in my beloved IDEA IDE – sometimes it worked as expected, sometimes the service was not injected and the test failed with a Null Pointer Exception.

It took me a while to figure out that the problem is related to the Run /Debug configuration. When IDEA applies a Run/Debug configuration in which the Integration Test is assigned to the Unit Tests Configuration, the Test is treated exaclty us such and consequently the Service is not injected.

The solution to the problem is therefore to make sure that your Integration Test is running inside the Grails Configuration in IDEA.

Grails and the Burning-Image Plugin on Windows

The Grails part is straight forward as documented. As for the Windows environment make sure that you have the jmagick.dll in your <JDK>/jre/bin directory and the jmagick.jar in the <JDK>/jre/lib directory.  Also make sure that the core_rl_magick_.dll is installed on your system. You can do so by downloading and installing an ImageMagick version that contains the dlls, e.g. ImageMagick-6.3.9-0-Q16-windows-dll.exe.

Grails and smartgwt

To set up a grails and smartgwt project basically follow this great tutorial by Peter Ledbrook.
The equally useful tutorial by Josip goes one step further.

1) Create a grails project

2) Install the gwt plugin

3) Install the smartgwt plugin

4) Create a module

5) Fill in the entry point: Create the DataSource and Form Classes. Attention: If you use Josips tutorial make sure that in the function

the formWindow.setHeaderControls(HeaderControls.HEADER_LABEL, closeControl); methode is called first thing before any of the other formWindow.set(..) methods, otherwise you get am IlegalStateException.
Check if the url to the controller that are called from within your RestDataSource are correct.

6) Inherit from smartgwt

7) Generate the gsp page that holds the gwt client and move it from the web-app to the grails-app/view directory.

8) Remove the grails main.css from the layout/main.gsp  page

9) Add

<script>var isomorphicDir = "gwt/org.example.SmartButton/sc/"</script> to the main.gsp page but leave gwt/ as is!

10) Alter the url mapping so that the gsp page holding the gwt client is loaded by default.

11)  Run the compile gwt module command

12)  Fire up grails and fire up the gwt-client

Grails and GWT in IntelliJ’s IDEA: Not a valid GWT installation Error

The other day I treated myself to a license of IntelliJ’s IDEA and I am loving it especially when working with Grails projects.

When I started toying around with the GWT plugin for Grails however, I ran into trouble because apparently the GWT_HOME environment variable that I defined for the bash shell is not visible to IDEA which results in a nasty ERROR: null is not a valid GWT installation show stopper – among others.

To solve the problem I created the file ~/.MacOSX/environment.plist and edited it so that it looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "">
<plist version="1.0">

In IDEA’s Run Debug configuration make sure that the include parent environment variables option is selected.
In this way any environment variable defined in the file environment.plist is passed to applications that are started from the finder such as IDEA.

Instead of defining GWT_HOME for the finder I could have added it to IDEA’s Run / Debug Configurations but the downside to this solution is that any script triggered by Run Target that depends on environment variables such as run-gwt-client would fall flat again.

Grails 1.3.6 Bug in jquery Tag: Page Reqeuest Instead of AJAX Call

There is a bug in Grails 1.3.6 that prevents (at least) the remoteLink to work correctly. Instead of calling the specified controller closure as an AJAX call, a normal page request is conducted resulting in a futile attempt to display a page on the part of the server.

Downloading the latest Grails 1.3.7-SNAPSHOT release solved the problem for me.

ActionsScript 3: Calling nonexisting methods

I have been wondering all along how it is possible to call a method that is not defined anywhere in that class and get something reasonable done, e.g. the method on the Cairngorm delegate that conducts the call to the server.

After playing around with Grails I became aware of the fact that this mechanism is used extensively not only in Grails but in other frameworks that are based on dynamic languages such as Ruby on Rails.

This great blog entry on lifts the veil and explains the magic.

Grails App-Engine deployment

When deploying a new version of my application (actually I started an entire project from scratch) I continuously bounced my head against this  “You don’t have the permission…” exception.

I finally added the following lines to my Configuration/config.groovy file:


where myproject is the part that appears in the url, like

Google App-Engine, Grails and Security

Here are the directions for a patch in a great Screencast by Tomás Lin that makes authentication work  in a Grails Application on Google’s App-Engine:

google.appengine.sessionEnabled = true // default true
google.appengine.enableSsl = true // default true = ["/secure", "/shoppingcart/*", "/admin"] = ["/admin", "/notsecuredadmin"] = ["/admin", "/", "/yabbadabbadoo"]

Don’t forget to apply the securePatch.diff patch to the plugin directory of your project – that is in <home>.grails/1.1.1/projects/myproject/plugins/app-engine-0.8.1 in order for these properties effectively written to the web.xml file.

Google App-Engine and Grails Dynamic Methods

A blog entry about running grails on Google’s App Engine. Among other things the methods that are provided by the App-Engine plugin are listed.

The added domain class MetaClass methods are:

  • save
  • get
  • delete
  • findAll
  • withTransaction
  • withPersistenceManager (to execute code with access to the PersistenceManager)
  • isJdoPersistent, isJdoDeleted, isJdoDetached, isJdoDirty, isJdoNew, isJdoTransactional, getJdoTransactionalObjectId, getJdoVersion, getJdoObjectId, and jdoMakeDirty corresponding to the JDOHelper methods isPersistent, isDeleted, isDetached, isDirty, isNew, isTransactional, getTransactionalObjectId, getVersion, getObjectId, and makeDirty

Controllers have these attributes added to their MetaClass:

  • params (with Request attributes like in Grails)
  • session
  • request
  • response
  • servletContext