Whether Websockets supersede other comparable technologies such as CometD/Bayeux protocol as some have suggested (Joe Armstrong, father of Erlang: WebSockets will kill Comet)  or do not go far enough (Greg Wilkins, co-creator of Jetty and the Bayeux protocol:  WebSocket specification needs improving) I would not want to hazard a guess.

It’s even possible that Websockets end up complimenting CometD in CometD version 2, as discussed here – but as noted by Greg Wilkins there are still issues left to resolve such as Keep Alives with a suggestion for a future version to support timeout discovery and Timeouts with suggested messages that can be used to distinguish between a network failure and an orderly close as the user leaves the page.

Anyway, considering that Websockets and HTML 5 is being sponsored by Google, Apple and others at the WhatWG working group and there are already HTML 5 capable browsers (Chrome, Safari) starting to  support the WebSocket protocol, I, in an attempt to better understand the technologies, decided to download Jetty and follow a simple Websocket Chat example.  After a few minutes I had the simple application up and running using Jetty and the Google Chrome browser.  However, I ran into an issue when trying to run the simple app using the Maven Jetty plugin, getting the following exception:

java.lang.NullPointerException        at
org.eclipse.jetty.websocket.WebSocketFactory.upgrade(WebSocketFactory.java:92)        at
org.eclipse.jetty.websocket.WebSocketServlet.service(WebSocketServlet.java:60)        at
javax.servlet.http.HttpServlet.service(HttpServlet.java:820)        at
org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:530)        at
...

<plugin>
	<groupId>org.mortbay.jetty</groupId>
	<artifactId>jetty-maven-plugin</artifactId>
	<version>7.0.2.RC0</version>
	<configuration>
		<scanIntervalSeconds>5</scanIntervalSeconds>
	</configuration>
	<dependencies>
		<dependency>
			<groupId>org.eclipse.jetty</groupId>
			<artifactId>jetty-websocket</artifactId>
			<version>7.0.2.RC0</version>
		</dependency>
	</dependencies>
</plugin>

Where I am working we are currently versioning files with the following naming scheme:

            nnn-a short script description.sql

where “nnn” is an incrementing version number.

In each database there is a database_updates table which is a simple record of which scripts have been applied and when (the scripts are expected to update this table – the actual script and the database_update are all done within a transaction).

It’s not at all uncommon for scripts to be committed with a particular version number into one working branch only to find when merging back down to the trunk that scripts exist with the same version numbers, despite being very different scripts.  The responsibility for this resides with the person doing the merge, as there is always the file name that can be used to distinguish scripts.  This is a less than perfect solution – and I for one would like be able to run scripts checked in and not have to worry about exceptions because a script with the same version number has already been applied (unless of course I am running a script that has been run before). Apart from being a little disconcerting there is the very real chance that a script will be ignored with the assumption that the script has already been applied – locally this isn’t such an issue but can cause delays in our production and staging environments.

Suggestions

Maybe I am making something out of nothing here and by simply using the same merge tools that are used for code; along with a little common sense these issues can be sorted.  Perhaps, but I can’t help but think there is a “nicer” solution. None of the following suggestions make sense unless you have “baselined” the database and can recreate from script, a known good staring point.

In no particular order:

• Separate repository for database scripts – perhaps using the svn:externals property to map a local directory to the URL-and possibly a particular revision-of the versioned resource: (http://svnbook.red-bean.com/en/1.1/ch07s04.html)
• Database scripts that are committed should be treated as immutable – there is no point of versioning a file and then modifying it – it may have already been executed and any subsequent changes may not get applied.
• File name is just version number so multiple scripts of the same number can not be added without a conflict and seeing as scripts should not be updated an svn merge is out of the question (or a “resolve with mine” type of operation). If this seems too restrictive (the file naming) perhaps an svn script can be written to check and reject a file if one with the same version prefix/suffix already exists?
• File names are named in such as way you know which version of the database it applies to

In Practice

Let’s say the database is baselined and versioned 1.000 and 15 change scripts are added (1.001 to 1.015).  At this point a release branch is created along with a version 2.000 schema script in the trunk  - this script will produce the same database as the original script plus the 15 change scripts.

New scripts added in the trunk are for the version 2 database, so if 4 scripts were added there would be scripts 2.001 to 2.004.  If a script is needed in the release branch – 1.016, the production system could simply receive this change as production is still running with version 1 – the problem is how to integrate 1.016 into the trunk.  One solution could be to create a new script in the trunk, 2.005, that has the 1.016 changes.  All version 1 databases can simply run all version 1 change scripts, version 2 databases start with the version 2 baseline script and apply any 2.x change scripts.

This works ok when branches are created for release as schema changes and code modification slow.  Hopefully only bug fixes are committed to the branch and not new features.  Modifications made in the branch are generally merged down to the trunk where work not scheduled for a particular release resumes.

This is all fine and dandy until we come to “feature” branches – this is where I get stuck

Suggestions most welcome!

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.

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!

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

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