Grails on The Google App Engine: Everything you wanted to know but were afraid to ask
I’ve been playing with Grails and the Google App Engine for about a month. Overall, I’ve been very happy about the experience. There seem to be a few questions and misconceptions about the app engine and Grails, both on forums, blogs and the Grails mailing list. I thought I would put together a quick summary for those looking for more information about deploying on this platform.
Disclaimer: I realize this might sound like me nitpicking on Grails and the GAE and wrote this article to spread Microsoft’s patented FUD, I actually do really enjoy the free bandwidth and monitoring tools provided. And developing in Grails does make things much easier. Please see my post 5 reasons for Flex developers to consider a Grails/Google App Engine backend for fluff. Realistically, you’re working with a plugin that is six weeks old and a platform announced less than two months ago. There are bound to be issues that will be solved soon.
Limitations of The Google App Engine
- The Google App Engine does NOT implement all aspects of J2EE. This is a pretty big one. It means that Grails plugins like ImageTools or JCaptcha won’t work because there is no support for awt.Font or BufferedImage. ( See the whitelist )
- You cannot write to the file system.
- There is no JDBC support (And no Hibernate). Thomas Mueller, the author of the H2 database, has it working in memory, but is still bound to the inability to write to a filesystem.
- You cannot use threads.
- There is a 1,000 file limitation on your web application.
- Your favorite Grails plugin probably doesn’t work. Again, due to the limitations of the App Engine mentioned above. A good page to keep an eye out for is Will It Play, which lists common libraries and their compatibilities. It might also be a good idea to start a Will It Play on GAE plugin page on Grails.org, but that’s up to the powers that be.
- There is very little documentation outside of the official docs. Again, because the platform is so new. The books are all about the Python platform. With that said, I do recommend reading Eugene Ciurana’s Developing with Google App Engine (Firstpress)
for a good overview of the App Engine Platform and design principles. There is also Charles Severance’s Using Google App Engine( python again – haven’t read it, but am open to free copies ;p ).
- You can build 10 apps. Apps cannot be deleted or renamed once created(ya, I know). You need a SMS capable phone to enable your account.
- You can’t build or design missiles, chemical or biological weapons with the App Engine.
JDO vs. JPA?
Whenever you give someone a choice, they’re bound to be pitted against each other. In the app-engine, you are able to use either JDO or JPA as the persistance mechanism. At the end of the day, they are both wrappers around the BigTable datastructure in the app engine. So which one do you choose?
JPA template support was added since version 0.8 of the App Engine, and it has a lot more momentum going forward. Specially with the jpa-gorm plugin in development. When this question was raised on the Grails mailing list, the direction seems to point to JPA as a better solution for this.
However, this doesn’t mean that you should absolutely discount JDO. Datanucleus, the persistence implementation shipped with the App Engine, support JDO and JPA equally. As I was learning to develop for the app engine, I did find the JPA documentation lacking ( perhaps because there are other places to find this info ) and more examples of JDO on the App Engine. This seems to be the consensus of some other bloggers. Here is an interesting discussion on JPA vs JDO on the App Engine.
I think that in the long run, JPA is your best bet for grails support. However, if you’re interested in deploying short-term toy applications or for learning purposes, JDO might be a better choice (until jpa-gorm comes out, that is).
The third option (obviously) is to convince your rich oil tycoon uncle to give Robert Fischer a gigantic suitcase of cash to write a bigtable-gorm plugin.
Known Issues with Grails on the App Engine ( and workarounds )
- Before you install everything, you also need to install the Google App Engine developer environment and set your variables. Version 1.2.0 is recommended for the app-engine plugin version 0.81.
- There is no GORM support yet. But the gorm-jpa plugin is coming along and this should not be a limitation any longer.
- File upload is broken due to Spring’s CommonsMultipartResolver writing to disk. A solution proposed was to write your own mulipart resolver.
- Grails templates are broken in edit/create templates for one-to-one relationships because someone decided to hardcode DomainClass.list in the templates. You can solve this by creating a list manually and then passing it to the template as a parameter. Or write your own .list dynamic wrapper.
- If you’re using the app-engine version 1.2.1, delete the datasources-index.xml file found in grails-app/conf/ or you’ll run into this issue. ( If you’re building indexes, remove the namespace reference inside the declaration ).
- The username and password entry when you try to deploy ignores the first line of input, you can either set there parameters in config.groovy –
google.appengine.email = “myemail@me.com”
google.appengine.password = “mypassword”
or just hit enter the first time the username and password prompt appears. - There seems to be a dependancy to hibernate with the generate-all command for templates. If you get an exception, re-install the hibernate plugin, then call generate-all. ( I haven’t ran into this ).
- You can’t use JSecurity, Authentication or Acegi plugins, but there is a patch for GAE role-based access.
Tips, Resources and other Tomfoolery
- There is also Groovlets and Grails Lite.
- The app-engine issue tracker and the app-engine for java google groups are very active and rich sources of information.
- Mor.ph and eapps have always come up in discussions for Grails hosting solutions if the app-engine doesn’t seem right to you.
- The app-engine plugin page is where all good things happen.
If there is anything that I’ve missed, post in the comments and I’ll update this.
Almost forgot the BLATANT PRODUCT PLACEMENT: Visit Empora.com for a cool way to shop for clothes online with futuristic and magical visual search technology.

Hi Tomas,
In your post “5 reasons for Flex developers to consider a Grails/Google App Engine backend” you mentioned
3 Bend Data
Grails takes a lot of powerful Java libraries and wraps them into easy to use Plugins. With Grails, …. Output data in PDF? RSS? iPhone view? Captchas? …….
I think you meant Grails + AppEngine supports Captchas. But in this post you said JCaptcha won’t work. Could you explain a bit?
By the way, I have started a small project with “Grails + mySQL on ubuntu” not long ago. Do you recommend if I should move to “Grails + AppEngine”?
Thanks for your advices,
Bendanpa
bendanpa
June 3, 2009 at 5:33 pm
You can still implement captchas with web services like ReCaptcha. If you look at the JCaptcha documentation, you will see that a default captcha is using awt.Font and awt.Color, which are not in the whitelist.
Look through the JPA or JDO documentation to convert your project, since there is no GORM. Or you can just wait for jpa-gorm.
Tomas Lin
June 3, 2009 at 5:40 pm
Nice summary
Well, JPA is the preferable wrapper to use for Grails@GAE development (suggested by Grails Head Graeme). And gorm-jpa was also released some weeks ago. My reference implementation for gorm-jpa/app-engine:
http://code.google.com/p/loxal/source/browse/trunk/market-agent/grails-app/domain/org/loxal/wenity/service/marketagent/Product.groovy
Alexander Orlov
July 17, 2009 at 9:06 am