Running Apache Camel within an Application Server

This week I needed to show a colleague how to use Apache Camel, Apache CXF and Spring to create a web-based integration application. To do so, I created a Camel-based implementation of the Simple Apache CXF examples I wrote in 2012. Although this topic is covered more than once on Camel documentation, some details are either missing, which can make it tricky to run this setup this the first time, or are specific to a the application server where the code will run.

Therefore, I created this example (which you can find in this repository in my GitHub account) to complement the official documentation with additional details. I used the open source GlassFish application server to run the code.

We start our service implementation by declaring a route for the service:

The important parts in the route declaration are:  loggingFeatureEnabled  and serviceClass. The former makes sure that the transactions are written to the log and the latter is the service endpoint interface (ie.: maps to the data type we are dealing with in this route). The serviceClass is required when working in POJO mode, which is the default data format unless specified with dataFormat option. The request is then processed by a processor, which we will use to manipulate the exchange and set the reply. This code can be made even simpler by using the Bean as a an endpoint, but we will discuss that later …

We are not processing anything from the request here, so this makes it very simple to handle the request. Had we the need to process them, we could do something like this:

With the Java code in place, we can now write the 3 XML files required to run this service. Since we are following Maven standards here, the files will reside in ${project.dir}/src/main/webapp/WEB-INF.

The first file is the Spring’s applicationContext.xml, where we will import the CXF servlet resource definitions and declare the routes:

The second file is the web.xml file. We will declare the Spring Context Loader Listener, to bootstrap our application. Among other things, this allow us to reconfigure log settings during startup so that we can properly log with log4j under GlassFish. We also declare the servlets in the web.xml file. The final result, which is slightly different that the one in the Camel In a Web Application example, since we don’t declare the location of our Spring XML files, can be seen below:

Finally, we come to the third file, which is specific to GlassFish and may vary according the application server. According to Apache CXF documentation, the Interceptors won’t work on GlassFish so we need to reconfigure the class loader. Failing to do so may cause weird problems. Here’s the file sample:

We also configure the context root, so it defaults to /camel-cxf-web/ instead of /camel-web-ws-server-1.0-SNAPSHOT/. Apart from the dependencies, this is pretty much all that is needed to implement a Camel-based web service that runs on an application server.

Bonus #1:

The sample code can be made much simpler by using a Bean endpoint. By doing so we can skip the whole TimeServiceProcessor code and have Camel deal directly with the TimeServiceBean:

Published by

Otavio Piske

Just another nerd

Leave a Reply

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