Camel CXF – X__project Supplement



This blog should be interesting only to someone actively attempting to get their first camel-cxf project working. It is a companion piece to a progression of 4 example projects, and the docs on each.

  1. Code first CXF – simple.
  2. WSDL first CXF – simple.
  3. Code first CXF – complex objects.
  4. WSDL first CXF – complex objects.

It is notable that none of the previous Camel example projects required anything close to this kind of documentation, or explanation.

Main Points:

If you are impatient, like me, you may find that getting to number 4, above, is needlessly difficult, the first time. Especially aggravating, given that number 4 is the only variant that commercial/corporate applications might accept.

Then, when you get it all done, you might wonder what the fuss was about. Maybe this blog and these projects will get you there without spending much time.

The idea is to be able to blast through each of these very quickly, picking up additional steps/dependencies with each one.

The Sequence:

  1. Code first simple – basic dependencies, server, testing, tooling.
  2. WSDL first simple – add WSDL first steps, code.
  3. Code first complex – adds objects for input and output, processing, and testing variants.
  4. WSDL first complex – adds a merge with your own entity code.

Again, once you know the above steps you’ll wonder what all the fuss was about. Until then I found lots of ways to guess wrong and waste lots of time.

Specific to WSDL-First:

If you are new to SOAP and WSDL first in general, there may be some confusion about the generated code step. Since there may be some options, here is what I found successful.

  • Just running mvn compile is enough to generate the wsdl2java step. It’s will place it wherever you told it to in your pom, or in this case target/generated/src/main/java.
  • Wasn’t sure if I should be making this a legit source folder? Or copy the code to my src/main/java? I chose the latter, see next step.
  • When you copy it to your source folder, there still may be plenty of changes you have to make by hand. For example, your complex input and output object entities may already be in your codebase, and the wsdl2java generates you new entities. So in that case, you would have to merge the generated into the previous entities and then modify the rest of the generated code to point to those, and not the generated. You then delete the generated.
  • You may also have to comment out your wsdl2java plugin code in the pom.xml as soon as you have copied over and modified any generated code. This may or may not be obvious, but will make itself quite obvious if it becomes an issue.

Consuming WSDL from CodeFirst

One possible source of confusion can be quickly clarified by acknowledging a cheat that was used on the two WsdlFirst projects.

One of the most significant challenges to a WSDL first project of any type is the creation of the initial WSDL. This file is a complex 5 part file with many cross-referencing parts. Not for sissies like me, putting together silly example projects.

What was done on these example projects was to create the WSDL using the code first project, which creates a wsdl and publishes it to the browser as part of it’s functionality set.

This WSDL was then hand copied to the correct folder in the WsdlFirst projects.

A side benefit was that the WsdlFirstComplex and CodeFirstComplex projects could then also share entity classes, but that is just a side effect. In this case, the shared entities were placed in the jammazwan.shared project. Both WsdlFirst and CodeFirst projects share the same test code, using this approach.

Running Your Test as a Server (WTH?)

Problem: Jammazwan example projects are for learning Camel, not production deployments. Server and deployment code is intentionally excluded so you can isolate only what you are learning. So what happens in a case like this, where we actually need a running server to test with during development?

Solution: A quick, and ugly, manual hack is provided in our test code. I cringe, but it works great for the learning process.

A more realistic solution begins to outline itself in my Camel Microservices blog, though that is a bit off topic for this article.


  • Write your project to test with a normal test, such as template.requestBody(), like any other camel route.
  • Once it’s working, test it in the real world using something like SoapUI. To do this, uncomment the hack line

    Thread.sleep(Long.MAX_VALUE); Ugh.

  • You may now run the test, and the test basically hangs. Whola! Your server is operating. Even if you are wincing in disgust.
  • From your camel-ctx.xml file, copy the url. Such as http://localhost:9876/passThru/
  • Append ‘?wsdl‘ to this line. You now have a wsdl url of http://localhost:9876/passThru/?wsdl
  • Open the wsdl url in your browser. My chrome browser shows the xml from the wsdl file.
  • Now you can take this same wsdl url to your SoapUI tool, and test the actual working server with actual working xml. I won’t cover this here, as it’s assumed you already have this skillset.
  • Now you can kill your running test, which never finished, and comment back out the Thread.sleep(). Your manual dev test is complete.

Remaining Documentation:

Each of the 4 cxf example projects is documented in their respective

The files each focus on a diff between that, and previous artifacts. So 4 isn’t so much of a standalone, as a diff between it’s artifacts, and the previous. Etc. Other x__projects are standalone, not these 4.

  1. Code first CXF – simple –
  2. WSDL first CXF – simple-
  3. Code first CXF – complex objects –
  4. WSDL first CXF – complex objects –