WildFly Camel4.0.0 has been released. This release is quite small compared to previous ones, but it does contain an interesting enhancement that is worthy of further explanation.
The state of WildFly Camel and Camel CXF
Thus far, the WildFly Camel subsystem has been compromised on its Camel CXF integration. Previously, there has been no support for
CXF-RS or CXF-WS consumers. Instead, the suggested workaround was to use the Camel Proxy idiom.
The reason for this, is that ideally we want the Camel CXF component to integrate with the WildFly Undertow HTTP engine, instead of starting its own HTTP engine. This
problem has been solved in the 4.0.0 release and thus Camel CXF integration is now greatly improved.
Camel CXF can now leverage the WildFly Undertow HTTP engine, together with its security and graceful showdown capabilities. Also, the Camel subsystem can utilise the
existing WildFly CXF modules that are used in the WildFly webservice JAX-WS subsystem.
Camel CXF-WS consumer
To demonstrate the CXF-WS consumer, I’ll be using Spring to specify the Camel route configuration.
When the application is deployed, it will expose a JAX-WS endpoint at http://localhost:8080/webservices/greeting. You
can verify that the endpoint is available by viewing the endpoint WSDL. Open the following URL in a web browser:
The producer configuration is similar to the consumer:
This improved CXF integration will make the Camel CXF user experience much nicer on WildFly Camel Subsystem. Almost any example that you find for standalone Camel
CXF should work perfectly well with WildFly Camel. Hopefully you’ll agree that this is a great improvement over the CXF integration that was present before.