Simple ESB with Camel and Groovy

I'm not sure if writing an ESB service can be considered fun - but when using Groovy and Camel together it comes pretty close. Camel provedes a nice Java based DSL which makes the routing very clean and easy to follow. When you mix in the power of Groovy you get a very elegant solution.

With Groovy you can say a closure implements an interface. This allows us to embed Groovy code inline as a Processor in a Camel route.

    from("jetty:http://localhost:8080/hello")
    .process({Exchange exchange ->
      exchange.out.setBody "Hello World"
    } as Processor)

We can go one step futher by taking advantage of Groovy's dynamic metaClass to create our own method which takes a closure directly. The following adds a new method 'x' to the RouteDefinition class.

RouteDefinition.metaClass.x = {Closure c -> ((RouteDefinition)delegate).process(c as Processor)}

Our route definition now becomes much more elegant

    from("jetty:http://localhost:8080/hello")
    .x {Exchange ex -> ex.out.setBody "Hello"}
    .x {Exchange ex -> ex.out.body = ex.in.body + " World"}

Add in some Grab annotations from Groovy's Grape extension to automatically download the Camel libraries and the whole thing becomes a single, small, self-contained script.

#!/usr/bin/env groovy

@Grab(group="org.apache.camel", module="camel-core", version="2.5.0")
@Grab(group="org.apache.camel", module="camel-jetty", version="2.5.0")
import org.apache.camel.CamelContext
import org.apache.camel.impl.DefaultCamelContext
import org.apache.camel.builder.RouteBuilder
import org.apache.camel.Processor
import org.apache.camel.Exchange
import org.apache.camel.model.RouteDefinition

RouteDefinition.metaClass.x = {Closure c -> ((RouteDefinition)delegate).process(c as Processor)}

CamelContext cxt = new DefaultCamelContext()

cxt.addRoutes(new RouteBuilder(){
  void configure(){
    from("jetty:http://localhost:8080/hello")
    .x {Exchange ex -> ex.out.setBody "Hello"}
    .x {Exchange ex -> ex.out.body = ex.in.body + " World"}
  }
})

cxt.start()

Git version control with a ClearCase like workspace

I have been using the git version control system for a while now. It took a little time to get comfortable with the commands and to fully understand everything it was doing.

When I first read about the fast branch switching I was envisioning something along the lines of a ClearCase view. It has been a while since I used ClearCase - but from what I remember when you switch from one view to another, the virtual file system saved your whole workspace (including things not checked in yet) and then restored your whole workspace from the new view to the exact state it was in when you left. Git doesn't work exactly this way.

When you change to another branch in git it only switches files it is tracking. Any new files you are working on are not affected and therefore appear to magically come over to the new branch. Also, any files you have changed that are tracked will come over if your changes do not cause a merge conflict.

Git does have a stash command that allows you to save off your changes and then apply them again later - but in my opinion it is a little cumbersome. It does not save new files - only ones that are currently tracked, and to apply a specific stash you have to look at the stash list and then apply one as a numerical offset.

For me I would much rather git worked like a clearcase view so that I can save my workspace as-is and then later load it back up. Luckily git is quite powerful and allows you to create some very complex aliases to use right along side other git commands. I created the following two aliases which can be added to your .gitconfig file.

    save = "!git add -A && BR=$(git symbolic-ref HEAD) && echo saving workspace ${BR##*/} && SAVE=$(git stash create Workspace) && git config workspace.${BR##*/}.save $SAVE && git reset --hard HEAD"

    load = "!BR=$(git symbolic-ref HEAD) && echo loading workspace ${BR##*/} && SAVE=$(git config --get workspace.${BR##*/}.save) && git stash apply -q $SAVE && git reset HEAD && git config workspace.${BR##*/}.hist $SAVE && git config --unset workspace.${BR##*/}.save"

Typing git save will save off your workspace as a revision and use a git variable to associate it with the current branch name. You can then change to another branch and come back later. When you come back, typing git load will look for the saved workspace revision associated to the current branch and reapply those changes. This will save and load all files (tracked and untracked) except for the ones you have specifically told git to ignore.

Simple Groovy POJO Builder

While using Groovy the other day I wanted to use the builder notation on some simple classes I had created.  The Groovy builder classes are very powerful and allow you to create some very nice custom builders - but that was a little more complex than I was wanting.

Given these simple classes:

class Company{
 public def name = ""
 public def deptList = []

 public add(Department d){
  deptList.add(d)
 }
}

class Department{
 public String name = "default"
 public def Employee = []
}

class Employee{
 public String name = "default"
}

I wanted to be able to write something like the following and have the builder dynamically match up all of the methods and properties without me doing anything.

def c = PojoBuilder.build(Company.class){
  name = "Acme"
  Department{
   name = "HR"
   Employee{
    name = "John"
   }
   Employee{
    name = "Jack"
   }
  }
  Department{
   name = "IT"
   Employee{
    name = "Jimmy"
   }
   Employee{
    name = "James"
   }
  }
 }

As it turns out, the code to achieve this is rather short thanks to the powerful features of Groovy. A method similar to the following is a good start for the build method and allows us to call a closure on an instance of our class. From this closure we have direct access to all of the objects properties and methods - so calling name = "Acme" just works.

class PojoBuilder{

 public static Object build(Class cls, Closure c){
  Object o = cls.newInstance()
  c.delegate = o
  c.resolveStrategy = Closure.DELEGATE_FIRST
  c.call()
  return o
 }

An interesting feature of this is that the Department {...} syntax looks like a method call with a closure as a single parameter. If our Company class had a method

Department(Closure c)

that method would get called... but we don't want to have to add methods like that to our simple classes.

Luckily Groovy has a missingMethod functionality on the MetaClass which gets called when any method is missing. We can use that to add in our own method which can find a class matching the name, check for any method called "add" that accepts our found class, and optionally any properties with the same name that are an ArrayList. If found, dynamically add that method to our class and call it.

The complete example can be found here. It also includes a nice feature where you pass in the classes you want to use and the names you want to use in your builder syntax.