Part 5

... Continued from Part 4

We continue from part 4 where we have the routing in place. However as you might have noticed we aren't quiet there yet with a nice solution, we are still coding to much. In this part we will look into to address these two concerns:

  • Starting Camel automatically
  • Using CXF directly

Starting Camel automatically

Our current deployment model is as a war and we have the web.xml to help start things. Well in fact we will leverage Spring to start the world (wink). We use it's ContextListener

Then we need a standard Spring XML file so we create a new file in src/main/resources and name it camel-config.xml. Before we start editing this XML file we need to link to it from the web.xml file. So we add this snippet to the web.xml:

Now we are ready to edit the camel-config.xml file that is a standard Spring XML bean file. So you can add standard spring beans and whatnot you like to do and can do with Spring.

Now we are nearly there, we just need to add Camel to the Spring XML file, so Spring knows Camel exists and can start it. First we need to add Camel to the schema location in the top of the XML file.

Now we are ready to let Spring and Camel work together. What we need to do is adding a CamelContext to the Spring XML file. Camel ships with a CamelContextFactoryBean that is a Spring factory bean we should use for creating and initializing the SpringCamelContext. SpringCamelContext is extending CamelContext to be Spring aware so Camel and Spring can work nicely together. For instance the Registry will now use Spring bean lookup. So any spring bean can now easily be lookup and used from Camel. Well back to today's lesson. So we can create a SpringCamelContext using the factory bean as illustrated below:

However this is not used very often as Spring has support for custom namespace, so Camel has a CamelNamespaceHandler so we can create Camel using nice XML syntax as:

Adding route builder

Now we have Camel integrated but we still need to add our route bulder that we did manually from the javacode as:

There are two solutions to this

  • using spring bean
  • package scanning

Using a spring bean we just declare the route builder using a regular spring bean:

And then we can refer to it from our CamelContext:

So now when Spring start's it will read the camel-context.xml file and thus also start Camel as well. As SpringCamelContext is spring lifecycle event aware, Camel will also shutdown when Spring is shutting down. So when you stop the web application Spring will notify this and Camel is also shutdown nice and properly. So as an end user no need to worry.

The package scanning solution is for convenience to refer to a java package and Camel will scan all classes within this package for RouteBuilder classes. If using this then you dont need to declare your route builder as a Spring bean. So the XML can be reduced to.

Using CXF directly

Now we have seen how you can leverage Spring to start Camel, in fact it handles the lifecycle of Camel, so you can say Camel is embedded with Spring in your application.

From the very start of this tutorial we have used CXF as the webservice framework and we haven't integrated it directly with Camel as it can do out-of-the-box. Camel ships with a camel-cxf component for integrating CXF directly within Camel routing. In our tutorial we are exposing a webservice so we want continue to do this. Before we continue let's recap at what the webservice implementation we have from part 4

We have already seen how we can get Spring starting Camel so the constructor method can be removed. What next is that the CamelContext needed in this code should be the one from our camel-context.xml file. So we change the code to use a plain setter injection (we can use Spring annotations and whatelse but we keep it simple with a setter):

And then we need to instruct Spring to set this property. Turning back to cxf-config.xml from part 4 we can add a reference to our camel context

So now we have two spring XML files

  • cxf-config.xml
  • camel-config.xml

And since cxf-config.xml is dependent on camel-config.xml we need to have correct ordering in our web.xml where we have defined the XML files to load by Spring. So we set the camel-config.xml before the cxf-config.xml so Spring have created the SpringCamelContext and registered it in its registry with the id = camel.

Sidenote on spring XML files

Icon

The solution presented here with two spring XML files (cxf-config and camel-config) that is pendent on each other and thus has to be ordered can also be done using a different solution. You can for instance add an import in cxf-config and only have the cxf-config listed in web.xml. Another solution is to merge the two files into one combined file. Yes you can add the camelContext in the cxf-config file.

But hey this isn't using CXF directly in the routing? Yes it's not but I wanted to show the halfway solution as well. What we have now is having Spring creating and handling lifecycle of Camel and showing how you can inject CamelContext using standard Spring into whatever code you have. This is very powerful as you can use the solution that you (or your team) already master and is familiar with. If they have Spring experience then the IoC principle of injecting resources is of course also possible with Camel as well. In fact it's a best practice principle. Later you will learn that you can inject other Camel types such as Endpoint, ProducerTemplate as well.

Using the camel-cxf component

Okay let's continue and try to integrate CXF directly into our routing in Camel. This can be a bit more tricky than at first sight. Our goal is to avoid implementing the ReportIncidentEndpoint as we did with our code in ReportIncidentEndpointImpl (see above). Camel should be able to handle this automatically and integrate directly within our route.

Before we started our routing using the Direct endpoint with "direct:start". We should replace this with the CXF endpoint.

But before going to far we have to make a few adjustments to the .wsdl file and it's location in our project folder. We move report_incident.wsdl from src/main/webapp/WEB-INF/wsdl* to src/main/resources as we want to be able to refer to it from within our route builder from Java code and thus it should be on the classpath for easy access. Secondly we have upgrade the CXF to a newer version and it identified a minor issue with the .wsdl file itself. We have to give the complexType a name otherwise we get some JAXB error.

So the .wsdl should be changed from:

To include a name attribute of the complex types:

Using CXF endpoint

Okay now we are ready to turn our attention to using CXF directly in Camel routing. So we zap ReportIncidentEndpointImpl as we no longer need this code. So what's left is:

  • FilenameGenerator.java
  • ReportIncidentRoutes.java
    And that is all what's needed, well for now... (wink)

The goal is to replace the previous staring endpoint ("direct:start") to the new starting CXF endpoint.

CXF endpoint can be configured in either or both CXF spring configuration file or/and in the route directly. It accepts one parameter and others are optional. The parameter it must have is the service class. The service class is the interface for the WSDL operation's. As we have the wsdl2java goal to generate this class for us, we have it already as org.apache.camel.example.reportincident.ReportIncidentEndpoint.

The other parameter we will provide is the url to the .wsdl file. And finally we must provide the http address we expose the webservice at. The URI is therefore:

Then we can replace "direct:start" with our cxf endpoint instead, so it's:

The next issue you might now have guessed is that before (in part 4) we did a traditional codeing style to start a task and return a response to the caller in the method:

As you can see the method reportIncident is invoked with the webservice input parameters and we return the response to to the webservice from the method. But our situation now is that we don't have this method anymore. So how do we return a response to the webservice?

Houston we have a problem! Well of course not but the mindset have to be changed slightly to understand the routing concept, and how it works. So let's step back a bit. What we have here is a webservice that we expose. And our webservice is synchronous request/response based so the caller waits for a response. This is a InOut Message Exchange Pattern. Camel will default use InOut for webservices so we don't need to specify this explicitly. When we have a InOut pattern then Camel will return the response to the original caller when the routes ends. Looking at our route we have:

When the route ends after the file endpoint has been processed Camel will return the OUT message to the original caller (the caller of the webservice). However our route currently as it stands have not set any OUT message, so this is what we need to do, transforming (Message Translator EIP) the message into the response. We will therefore use a processor where we have 100% control in the Java code to set the response.

And with the route:

The route using the inlined processor is a bit ugly as we have high level routing logic combined with low level java code. First of all I wanted to show how flexible Camel is, allowing use as a developer to always be in control and can use Java code for whatever you needs is. First of all we could move the code into a inner class and just refer to it:

And then out route is much nicer:

Since our response is static and we don't need to any code logic to set it we can use the transform DSL in the route to set a constant OUT message. So we refactor the code a bit to loose the processor. First we define the OK response as:

And then we can refer to it in the route as a constant expression:

Important issue regarding using CXF endpoints in Camel

Now we are nearly there, there is an important issue left with using CXF endpoints in Camel. In part 4 we started the route by sending the InputReportIncident object containing the webservice input. Now we are using CXF endpoints directly in our routing so its a CxfExchange that is created and passed in the routing. CxfExchange stores the payload in a CXF holder class org.apache.cxf.message.MessageContentsList. So to be able to get our InputReportIncident class we need to get this object from the holder class. For this we show how it's done in Java using a processor, then later we show a nicer solution.

Well this isn't the nicest code, but again we want to show how it's done using plain Java, that is actually how Camel also can assist you in this nicer solution - we simply convert the body to the expected type using convertBodyTo. This is an important feature in Camel and you can use it for other situations as well.

Now the route is nice and simple.

Unit testing

Now lets turn our attention to unit testing it. From part 4 we have an unit test that is capable of exposing a webservice and send a test request and assert a mail is received. We will refactor this unit test to start up Camel, as it's Camel that should expose the webservice.

As Camel is very flexible we can create a camel context, add the routes and start it in 3 lines of code so we do it:

And the rest of the unit test is quite self documenting so we print it here in full:

Conclusion

We have now seen how we have created a much nicer solution leveraging Camel's powerful routing capabilities.

What we have here is routing logic with the help of the code comments could be understood by non developers. This is very powerful. In a later part we will look at some of the tools that Camel provides, for instance a tool to generate a nice diagrams of your routes (wink)

In the next part's look at using XML to create the route instead of Java code. Then it might be even more readable by non developers.

© 2004-2014 The Apache Software Foundation.
Apache Camel, Camel, Apache, the Apache feather logo, and the Apache Camel project logo are trademarks of The Apache Software Foundation. All other marks mentioned may be trademarks or registered trademarks of their respective owners.
Graphic Design By Hiram