Google App Engine and Groovy

Getting Groovy working on the Google App Engine required a few tweaks, thankfully the SpringSource Groovy and Google App Engine Java teams stepped up and worked together on various details including the area of constrained and strict security manager policies, to ensure development on the Java platform can take advantage of Groovy as a dynamic language. An updated Groovy 1.6.1 version is ready and by adding the “groovy-all” JAR in your WEB-INF/lib directory you can get start writing your applications in Groovy.

Following on from my previous post on Google App Engine I thought I’d have a stab at getting a Groovy application up and running with the App Engine plaform myself! I followed Guillaume Laforge’s excellent blog: “write your Google App Engine applications in Groovy!”.

After following Guillaume Laforge’s mini tutorial I tried to get the test project working within my Eclipse Google App Engine environment – this wasn’t as straightforward as I would have expected. I kept getting the following exception when trying to launch the application locally (this appears to be a local environment issue only):
java.security.AccessControlException: access denied
    (groovy.security.GroovyCodeSourcePermission /groovy/shell)

After a bit of playing around and searching I found I wasn’t the only one with this problem, and a bug has been raised concerning this.

To get the application working locally I needed to add the groovy-all-1.6.1.jar to the libraries in the Java Build Path – although this allowed me to run the application I have been unable to make changes to any Groovy code (that requires a compilation) without a restart – updates to GSPs and Groovlets seem to be fine.

 

Improving the feedback loop in Java with JavaRebel

One of the things that I have come to really appreciate about the .NET platform, coming from a Java background, is the increased productivity you get with such an integrated IDE and the runtime – no need to archive up artefacts and deploy to a container (in the Java sense that is, I know .NET has assemblies).  The ‘feed-back loop’ is greatly reduced and by this I mean the amount of time between making a change in code and seeing the results in the execution of your application on the screen.  

I know there are a number of tricks you can do with Java and various containers with exploded WARs and improved “Hot deployments” but I was blown away when recently discovering JavaRebel from Zeroturnaround.  How I wished I had this neat little JVM plugin when I was developing production code in Java – now, it’s saving me time with some home grown projects – just to keep my finger in Java (so to speak).

Without going into all the details – as it’s better explained on the Zero turnaround site this is all that is required to add the plugin to the JVM:

-noverify -javaagent:/path/to/javarebel/lib/javarebel.jar -Drebel.dirs=/paths/to/class/folders/bin

As I am running with the Springframework I also had to add:

-Drebel.spring_plugin=true

See Integrating JavaRebel with Spring

There are a number of other ways to integrate and a few extras such as a Maven plugin – just to make things even easier!

 

Google App Engine

 

With the recent announcement that Google App Engine has added Java support I thought I’d have a little go myself to see just how easy it is to get an application up and running.

Getting Started

First things first, I registered a Google account with the Google App Engine – an account is required to manage the applications in the “cloud”.

Next I downloaded and installed the Google App Engine Java SDK – actually, I downloaded and installed the Google Plugin for Eclipse that includes the SDK. The plugin for Eclipse 3.4 (Ganymede) can be downloaded from http://dl.google.com/eclipse/plugin/3.4 (for full steps checkout the Google online documentation).

With the plugin and SDK installed Eclipse has some nice new icons in the tool bar:

Now it’s time to create an application!

To create a “New Web Application Project” select  or via the menu: File > New > Web Application Project.  Provide a project and package name for the application then uncheck “Use Google Web Toolkit” and leave “Use Google App Engine” activated. This will create a skeleton project with a simple “Hello, World” example with a typical web application directory structure – nothing out of the ordinary:

src/
  guestbook/
    server/
      GuestbookServlet.java
    META-INF/
      jdoconfig.xml
    log4j.properties
    logging.properties
war/
  WEB-INF/
    classes/
      ...Eclipse compiled classes...
    lib/
      ...App Engine JARs...
    appengine-web.xml
    web.xml
  index.html

You’ll notice that the Java code resides in the src/ directory, code is compiled and class files are copied to the war/WEB-INF/classes directory.   Other non-code files, such as log4j.properties etc. are also copied to the war/ directory structure as the Eclipse plugin uses the war/ directory for running the development server, and for deploying the app to App Engine

Running the application

The great thing about the App Engine SDK is that you do not have to deploy to it to see your handy work, this is because the SDK includes a web server inside the Eclipse debugger that will simulate the live environment. To run locally, simply select the Run menu, Debug As > Web Application. Eclipse will build the project and switch to the Debug perspective. If all has gone well and the server starts successful you should see several messages, including:

The server is running at http://localhost:8080/

Open this URL in your browser and you should see your first App Engine application!

In Eclipse, you can make changes to source code including JSPs, static files and the appengine-web.xml and they will be dynamically reloaded when you save file as long as you leave the server running in the debugger. If you need to change the web.xml or other configuration files, you will need to restart the server for the changes to take effect.

Deploying to App Engine

To upload an application for the first time it needs to be registered with an associated application ID, this can be done using the Admin Console. Once the application is registered edit the appengine-web.xml file and change the  <application>...</application>  element to contain the new application ID.

Now we can simply use the deploy button:   to deploy the application to the App Engine – this will prompt you for your administrator account username (your email address) and password.   

Once deployed test your application on App Engine by visiting its URL:
http://<your application ID>.appspot.com/guestbook

 

Getting Groovy

Since starting my new job with Zyb I’ve been immersed with C# and the .NET platform, all new and great stuff.  Today, however, I decided to have another look at Groovy and the Grails framework and stumbled across the GroovyMag (just shows how long ago it was that I’d last looked at Groovy).  The current issue is: http://www.groovymag.com/main.issues.description/id=8/ 

GroovyMag April

and is well worth a read.  Inside the April edition is an article by Jeremy Anderson (http://blog.code-adept.com/) on Groovy and Flex and it demonstrates just how easy it is to expose Grails services for Flex remoting.

Utilising the Flex plugin (http://docs.codehaus.org/display/GRAILS/Flex+Plugin) to provide integration between Grails and Flex/BlazeDS you can get a rich internet application (RIA) up and running in next to no time.  The plugin automtically provides the configuration required for servlets etc. in the web descriptor and takes advantage of the reloading facilities of Grails registering services with the Flex message broker without the need for an application restart (although any modifications to the Flex app itself seemed to require a restart…).

To expose a Grails service for Flex remoting simply add the expose property to your service class:

class SimpleService {
  static expose = ['flex-remoting']
  def doSomething() {
    return "This is so easy"
  }
}

Now you can use the service within your Flex application without any other configuration by referencing thus:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">
    <mx:RemoteObject id="simpleService " destination="simpleService "/>
    <mx:Button label="Click me!!" click="simpleService.doSomething()"/>
    <mx:TextInput text="{simpleService.doSomething.lastResult}"/>
</mx:Application>

The example above is very straight forward – for a more indepth tutorial see the GroovyMag or Marcel Overdijk’s blog:  http://marceloverdijk.blogspot.com/search/label/Flex