Moving from Mor.ph AppSpace to Google AppEngine isn’t as easy as I hoped.

Installing AppEngine plug in

Initially moving the Application by installing the app-engine plug in is straight forward. Except that the command-line written in the plug in page for executing the initial setup is wrong. Ive corrected it now.

Windows users need to run the update command with the following command-line:

%APPENGINE_HOME%/bin/appcfg.cmd update ./target/war

Also unless the app-engine code executes correctly it will not clean up the staging directory. This causes problems if your using plug ins such as the ui-performance plug in. That is written to execute on a “clean” staging directory. If you it’s not cleaned up the plug in will try to compress the gziped version the files as well.

GORM

The problem however is that the GORM functions are not available, since the AppEngine is using a different data storage not supported by Hibernate.

There is a solution to this, install the GORM-JPA plug in. This gives you most GORM functions, but using Google AppEngines data storage.

Issues

From here I’ve run into several issues along the way. The framework for deploying to Google AppEngine crashes when running on Windows machines; if you have allot of libraries and classes in your project. Google AppEngine fails to save my entities, JSON conversion is acting up as it tries to serialize class meta data for some reason, which is were I’m currently stuck.

Light at the end of the Tunnel

Now I’d also like to mention that these issues are being ironed out. There are people looking at most of them, it’s just that Grails on Google AppEngine is relatively young so to speak. Even Java on Google AppEngine is quite new, if not Google AppEngine in it self.

Also I’d also like to mention the dashboard on Google AppEngine. It’s great!

The Dashboard on Google AppEngine gives the overview logs I got from Mor.ph, but they are presented better. They also give me some summaries on where most errors occur (which URLs crash) and which URLs are consuming the most CPU. This helps me to optimize specific URLs.

Since my application uses a REST service consumed through AJAX I can optimize parts of the application on the back end, and monitor the usage of parts of the web service.

I ran into a problem with Grails on Google AppEngine. When I was saving my entities it tried to save the wrong type of entity. I ran out of ideas on this one and brought it up on the Grails User mailinglist.

I started to work on some reproduction code and then I went to Denmark for some vacation. When I get back however, Keith Thomas had run into the same issue and figured out that it had something to do with the constraints on the domain classes.

Sure enough removing the constraints fixed the issue with saving. Ill try to see if the problem is specific to some kinds of constraints, since I still have my reproduction project to test it in.

I suggest a temporary fix to the described problems here.

I’m porting my Grails project from Mor.ph to Google AppEngine. If your using Windows certain things will not work out of the box.

To be able to use GORM you need to install the GORM-JPA plugin. Now you should in theory be able to use the GORM dynamic functions.

Alas however installing the GORM-JPA plugin will make the packaging functions for Google AppEngine fail. Google has a step in the deployment process where they enhance the byte-code to allow storage in their storage solution.

You run into this error

... java.io.IOException: CreateProcess: ...

Windows can only support command-lines with a length of 8191. The enhancement step reaches this limit when enhancing Grails applications. The Eclipse plugin has this issue mentioned here.

I’ve tried the following workarounds, with no luck:

• Running the packaging step in Powershell, hoping that powershell doesn’t have this limit.
• Running the packaging step in Cygwin, hoping that the linux emulation would work around the process execution limit.

Currently I’m working on rewriting the ant macro for the enhancement step in Google’s SDK. There are some improvements that can be done.

This is what the macro looks like in ant-macros.xml

 <!--
 A macrodef for ORM enhancement for a war. Use like:

 <enhance_war war="${war}"/>  
 -->
 <macrodef name="enhance_war" description="Run the ORM enhancer on an exploded war">
 <attribute name="war" description="The exploded war directory containing the application"/>
 <element name="args" optional="true" description="Additional arguments to the enhancer"/>
 <sequential>
 <enhance failonerror="true">
 <args/>
 <classpath>
 <pathelement path="${appengine.tools.classpath}"/>
 <pathelement path="@{war}/WEB-INF/classes"/>
 <fileset dir="@{war}/WEB-INF/lib" includes="*.jar"/>
 </classpath>
 <fileset dir="@{war}/WEB-INF/classes" includes="**/*.class"/>
 </enhance>
 </sequential>
 </macrodef>

Notice that the class path argument contains a fileset of the lib directories. This can be changed to just include the path element, since Java will resolve the .jar files.

The second part of the problem is the argument fileset list

 <fileset dir="@{war}/WEB-INF/classes" includes="**/*.class"/>

Grails creates a lot of class files, so just fixing the class path will not fix the command line problem. Ive been working on excluding files that do not need enhancement, such as the app-engine plugin classes themselves. Another idea is to move the domain into its own package, thus its own directory. This however leads to issues with naming, apparently the compiled groovy classes are not named according to how Datanucleus would like it.

I tried using the Datanucleus tool directly without success.

The latest Idea I have is to somehow wrap into the compilation step of the grails war target and do the enhancement there, and turn the enhancement step off when using just the app-engine plugin.