Tutorial using Axis 1.4 with Apache Camel
Removed from distribution
This example has been removed from Camel 2.9 onwards. Apache Axis 1.4 is a very old and unsupported framework. We encourage users to use CXF instead of Axis.
This tutorial uses Maven 2 to setup the Camel project and for dependencies for artifacts.
This sample is distributed with the Camel 1.5 distribution as
Apache Axis is/was widely used as a webservice framework. So in line with some of the other tutorials to demonstrate how Camel is not an invasive framework but is flexible and integrates well with existing solution.
We have an existing solution that exposes a webservice using Axis 1.4 deployed as web applications. This is a common solution. We use contract first so we have Axis generated source code from an existing wsdl file. Then we show how we introduce Spring and Camel to integrate with Axis.
This tutorial uses the following frameworks:
- Maven 2.0.9
- Apache Camel 1.5.0
- Apache Axis 1.4
- Spring 2.5.5
Setting up the project to run Axis
This first part is about getting the project up to speed with Axis. We are not touching Camel or Spring at this time.
Axis dependencies is available for maven 2 so we configure our pom.xml as:
Then we need to configure maven to use Java 1.5 and the Axis maven plugin that generates the source code based on the wsdl file:
We use the same .wsdl file as the Tutorial-Example-ReportIncident and copy it to
Okay we are now setup for the contract first development and can generate the source file. For now we are still only using standard Axis and not Spring nor Camel. We still need to setup Axis as a web application so we configure the web.xml in
The web.xml just registers Axis servlet that is handling the incoming web requests to its servlet mapping. We still need to configure Axis itself and this is done using its special configuration file
server-config.wsdd. We nearly get this file for free if we let Axis generate the source code so we run the maven goal:
The tool will generate the source code based on the wsdl and save the files to the following folder:
This is standard Axis and so far no Camel or Spring has been touched. To implement our webservice we will add our code, so we create a new class
AxisReportIncidentService that implements the port type interface where we can implement our code logic what happens when the webservice is invoked.
Now we need to configure Axis itself and this is done using its
server-config.wsdd file. We nearly get this for for free from the auto generated code, we copy the stuff from
deploy.wsdd and made a few modifications:
The globalConfiguration and transport is not in the deploy.wsdd file so you gotta write that yourself. The service is a 100% copy from deploy.wsdd. Axis has more configuration to it than shown here, but then you should check the Axis documentation.
What we need to do now is important, as we need to modify the above configuration to use our webservice class than the default one, so we change the classname parameter to our class AxisReportIncidentService:
Running the Example
Now we are ready to run our example for the first time, so we use Jetty as the quick web container using its maven command:
Then we can hit the web browser and enter this URL:
http://localhost:8080/camel-example-axis/services and you should see the famous Axis start page with the text And now... Some Services.
Clicking on the .wsdl link shows the wsdl file, but what. It's an auto generated one and not our original .wsdl file. So we need to fix this ASAP and this is done by configuring Axis in the server-config.wsdd file:
We do this by adding the wsdlFile tag in the service element where we can point to the real .wsdl file.
First we need to add its dependencies to the pom.xml.
Spring is integrated just as it would like to, we add its listener to the web.xml and a context parameter to be able to configure precisely what spring xml files to use:
Next is to add a plain spring XML file named axis-example-context.xml in the src/main/resources folder.
The spring XML file is currently empty. We hit jetty again with
mvn jetty:run just to make sure Spring was setup correctly.
We would like to be able to get hold of the Spring ApplicationContext from our webservice so we can get access to the glory spring, but how do we do this? And our webservice class AxisReportIncidentService is created and managed by Axis we want to let Spring do this. So we have two problems.
We solve these problems by creating a delegate class that Axis creates, and this delegate class gets hold on Spring and then gets our real webservice as a spring bean and invoke the service.
First we create a new class that is 100% independent from Axis and just a plain POJO. This is our real service.
So now we need to get from AxisReportIncidentService to this one ReportIncidentService using Spring. Well first of all we add our real service to spring XML configuration file so Spring can handle its lifecycle:
And then we need to modify AxisReportIncidentService to use Spring to lookup the spring bean id="incidentservice" and delegate the call. We do this by extending the spring class
org.springframework.remoting.jaxrpc.ServletEndpointSupport so the refactored code is:
To see if everything is okay we run
In the code above we get hold of our service at each request by looking up in the application context. However Spring also supports an init method where we can do this once. So we change the code to:
So now we have integrated Axis with Spring and we are ready for Camel.
Again the first step is to add the dependencies to the maven pom.xml file:
Now that we have integrated with Spring then we easily integrate with Camel as Camel works well with Spring.
Camel does not require Spring
Camel does not require Spring, we could easily have used Camel without Spring, but most users prefer to use Spring also.
We choose to integrate Camel in the Spring XML file so we add the camel namespace and the schema location:
Store a file backup
We want to store the web service request as a file before we return a response. To do this we want to send the file content as a message to an endpoint that produces the file. So we need to do two steps:
- configure the file backup endpoint
- send the message to the endpoint
The endpoint is configured in spring XML so we just add it as:
In the CamelContext we have defined our endpoint with the id
backup and configured it use the URL notation that we know from the internet. Its a
file scheme that accepts a context and some options. The contest is
target and its the folder to store the file. The option is just as the internet with ? and & for subsequent options. We configure it to not append, meaning than any existing file will be overwritten. See the File component for options and how to use the camel file endpoint.
Next up is to be able to send a message to this endpoint. The easiest way is to use a ProducerTemplate. A ProducerTemplate is inspired by Spring template pattern with for instance JmsTemplate or JdbcTemplate in mind. The template that all the grunt work and exposes a simple interface to the end-user where he/she can set the payload to send. Then the template will do proper resource handling and all related issues in that regard. But how do we get hold of such a template? Well the CamelContext is able to provide one. This is done by configuring the template on the camel context in the spring XML as:
Then we can expose a ProducerTemplate property on our service with a setter in the Java code as:
And then let Spring handle the dependency inject as below:
Now we are ready to use the producer template in our service to send the payload to the endpoint. The template has many sendXXX methods for this purpose. But before we send the payload to the file endpoint we must also specify what filename to store the file as. This is done by sending meta data with the payload. In Camel metadata is sent as headers. Headers is just a plain
Map<String, Object>. So if we needed to send several metadata then we could construct an ordinary HashMap and put the values in there. But as we just need to send one header with the filename Camel has a convenient send method
sendBodyAndHeader so we choose this one.
The template in the code above uses 4 parameters:
- the endpoint name, in this case the id referring to the endpoint defined in Spring XML in the camelContext element.
- the payload, can be any kind of object
- the key for the header, in this case a Camel keyword to set the filename
- and the value for the header
Running the example
We start our integration with maven using
mvn jetty:run. Then we open a browser and hit
http://localhost:8080. Jetty is so smart that it display a frontpage with links to the deployed application so just hit the link and you get our application. Now we hit append /services to the URL to access the Axis frontpage. The URL should be
You can then test it using a web service test tools such as SoapUI.
Hitting the service will output to the console
And there should be a file in the target subfolder.
We would like to be able to unit test our ReportIncidentService class. So we add junit to the maven dependency:
And then we create a plain junit testcase for our service class.
Then we can run the test with maven using:
mvn test. But we will get a failure:
What is the problem? Well our service uses a CamelProducer (the template) to send a message to the file endpoint so the message will be stored in a file. What we need is to get hold of such a producer and inject it on our service, by calling the setter.
Since Camel is very light weight and embedable we are able to create a CamelContext and add the endpoint in our unit test code directly. We do this to show how this is possible:
So now we are ready to set the ProducerTemplate on our service, and we get a hold of that baby from the CamelContext as:
And this time when we run the unit test its a success:
We would like to test that the file exists so we add these two lines to our test method:
Smarter Unit Testing with Spring
The unit test above requires us to assemble the Camel pieces manually in java code. What if we would like our unit test to use our spring configuration file axis-example-context.xml where we already have setup the endpoint. And of course we would like to test using this configuration file as this is the real file we will use. Well hey presto the xml file is a spring ApplicationContext file and spring is able to load it, so we go the spring path for unit testing. First we add the spring-test jar to our maven dependency:
And then we refactor our unit test to be a standard spring unit class. What we need to do is to extend
AbstractJUnit38SpringContextTests instead of
TestCase in our unit test. Since Spring 2.5 embraces annotations we will use one as well to instruct what our xml configuration file is located:
What we must remember to add is the classpath: prefix as our xml file is located in
src/main/resources. If we omit the prefix then Spring will by default try to locate the xml file in the current package and that is org.apache.camel.example.axis. If the xml file is located outside the classpath you can use file: prefix instead. So with these two modifications we can get rid of all the setup and teardown code we had before and now we will test our real configuration.
The last change is to get hold of the producer template and now we can just refer to the bean id it has in the spring xml file:
So we get hold of it by just getting it from the spring ApplicationContext as all spring users is used to do:
Now our unit test is much better, and a real power of Camel is that is fits nicely with Spring and you can use standard Spring'ish unit test to test your Camel applications as well.
Unit Test calling WebService
What if you would like to execute a unit test where you send a webservice request to the AxisReportIncidentService how do we unit test this one? Well first of all the code is merely just a delegate to our real service that we have just tested, but nevertheless its a good question and we would like to know how. Well the answer is that we can exploit that fact that Jetty is also a slim web container that can be embedded anywhere just as Camel can. So we add this to our pom.xml:
Then we can create a new class AxisReportIncidentServiceTest to unit test with Jetty. The code to setup Jetty is shown below with code comments:
Now we just need to send the incident as a webservice request using Axis. So we add the following code:
And now we have an unittest that sends a webservice request using good old Axis.
Both Camel and Spring has annotations that can be used to configure and wire trivial settings more elegantly. Camel has the endpoint annotation
@EndpointInjected that is just what we need. With this annotation we can inject the endpoint into our service. The annotation takes either a name or uri parameter. The name is the bean id in the Registry. The uri is the URI configuration for the endpoint. Using this you can actually inject an endpoint that you have not defined in the camel context. As we have defined our endpoint with the id backup we use the name parameter.
Camel is smart as
@EndpointInjected supports different kinds of object types. We like the ProducerTemplate so we just keep it as it is.
Since we use annotations on the field directly we do not need to set the property in the spring xml file so we change our service bean:
Running the unit test with
mvn test reveals that it works nicely.
And since we use the
@EndpointInjected that refers to the endpoint with the id backup directly we can loose the template tag in the xml, so its shorter:
And the final touch we can do is that since the endpoint is injected with concrete endpoint to use we can remove the
"backup" name parameter when we send the message. So we change from:
To without the name:
Then we avoid to duplicate the name and if we rename the endpoint name then we don't forget to change it in the code also.
This tutorial hasn't really touched the one of the key concept of Camel as a powerful routing and mediation framework. But we wanted to demonstrate its flexibility and that it integrates well with even older frameworks such as Apache Axis 1.4.
Check out the other tutorials on Camel and the other examples.
Note that the code shown here also applies to Camel 1.4 so actually you can get started right away with the released version of Camel. As this time of writing Camel 1.5 is work in progress.