Jun 7, 2016

Using Apache Camel in Grails 3

Grails 2 has a plugin for Apache Camel called Routing but that plugin hasn’t been upgraded to Grails 3 yet. Luckily, Grails 3 is just Spring Boot so we can use the Camel Spring Boot component…. with some caveats.

After you add the Camel component and a domain object or two, and do a grails run-app you will see something like this:

Field error in object 'Foo' on field 'version': rejected value [2.15.5]; codes [Foo.version.typeMismatch.error,Foo.version.typeMismatch,foo.version.typeMismatch.error,foo.version.typeMismatch,typeMismatch.Foo.version,typeMismatch.version,typeMismatch.java.lang.Long,typeMismatch]; arguments [version]; default message [Unable to parse number [2.15.5]

… and I was using Camel 2.15.5 in my project. Oh no… well it seems that Camel uses version in it’s Exchange metadata and it sees version in the domain objects and just inserts it’s version number there. No cool. To stop this, you need to add the following to your Grails 3 config:

grails:
   gorm:
      autowire: false

This will disable injecting beans into your domain classes… this is not something I do very often so I’m fine with it, but your use cases may vary.

After this, it’s pretty easy. I create a service with grails create-service Route then put the following in:

import org.apache.camel.builder.RouteBuilder;

public class RouteService extends RouteBuilder {
    @Override
    public void configure() throws Exception {
        from("timer://foo?delay=1").to("log:bar?level=ERROR");
    }
}

And when you now run grails run-app you see that the route is running because you see these log messages.

ERROR bar - Exchange[ExchangePattern: InOnly, BodyType: null, Body: [Body is null]]
ERROR bar - Exchange[ExchangePattern: InOnly, BodyType: null, Body: [Body is null]]
ERROR bar - Exchange[ExchangePattern: InOnly, BodyType: null, Body: [Body is null]]
ERROR bar - Exchange[ExchangePattern: InOnly, BodyType: null, Body: [Body is null]]

About the Author

Mike Hostetler profile.

Mike Hostetler

Principal Technologist

Mike has almost 20 years of experience in technology. He started in networking and Unix administration, and grew into technical support and QA testing. But he has always done some development on the side and decided a few years ago to pursue it full-time. His history of working with users gives Mike a unique perspective on writing software.

One thought on “Using Apache Camel in Grails 3

  1. KP says:

    It has been ported to Grails 3. See here – https://github.com/padcom/grails-routing
    It’s just not been officially published to the repo – https://github.com/padcom/grails-routing/issues/53

  2. Andrey Volkov says:

    I spent a few hours to find and understand the issue with Camel and Grails! It looks like epic fail in integration of these 2 big whales.
    Thank you for this simple workaround.

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Blog Posts
Up to Spec: JavaScript Numeric Separators
Let's take a look at the proposal to add Numeric Separators to the JavaScript specification.
Using Conftest to Validate Configuration Files
Conftest is a utility within the Open Policy Agent ecosystem that helps simplify writing validation tests against configuration files. In a previous blog post, I wrote about using the Open Policy Agent utility directly to […]
SwiftGen with Image & Color Asset Catalogs
You might remember back in 2015 when iOS 9 was introduced, and we were finally given a way to manage all of our assets in one place with Asset Catalogs. A few years later, support […]
Tracking Original URL Through Authentication
If you read my other post about refreshing AWS tokens, then you probably have a use case for keeping track of the original requested resource while the user goes through authentication so you can route […]