This release in particular added a number of new camel components to the subsystem and added support for the WildFly domain mode. Other than packaging and bootstrapping Camel in Java EE 7 yourself, this subsystem installs Camel directly into your WildFly 8.x server. As far as I know it even works with the latest 8.2.0.Final but isn't tested against it. Not, that there is a very light and easy way to bootstrap Camel in Java EE 7, but this approach enables even more integrations with Java EE standards. The ultimate goal for the subsystem is to provide Camel features as a directly usable option in WildFly without the need to configure or deploy anything. This is the main difference between a simple module and a complete subsystem.
Getting Started
Install WildFly 8.x by downloading the "Java EE7 Full & Web Distribution" from wildfly.org. Install by just extracting it into a folder of your choice. Next step is to download the distribution patch (53 MB, tar.gz) for WildFly from the JBoss Maven repository. After the download, navigate to the WildFly folder and extract the archive into it. That's it. Now start either standalone or domain mode with the respective *-camel.xml:
$ bin/standalone.sh|bat -c standalone-camel.xmlSome More Configuration
After we did that, you need to add some more users. First of all the management user.
$ bin/add-user.sh|bat
Call it whatever you like. For convenience reasons I tend to name it admin with the password admin. But please keep in mind, that this is the worst practice you could apply ;)
After you're done with that, add another application user. To make it simple, we just name it the same with the same, insecure password.
After you integrated the subsystem into your WildFly you can find the Apache Camel and JBoss modules in the module folder. The standalone\deployments folder contains two war-files. One of them is HawtIo and the other one is the wildfly-camel.war which is basically the camel-cdi example but more on that later. First of all, point your browser to: http://localhost:8080/hawtio/ and login with the application user you created.
You can see, that the ActiveMQ and Camel tabs are enabled, which means both modules have been deployed and discovered by HawtIo. Drilling down into the Camel tab you can see two deployed routes. The versions used for the integration are Apache Camel 2.14.0, HawtIo 1.4.22 and Arquillian 1.1.2.Final.
High Level Features
The strategy of wildfly-camel is, that a user can “just use” the camel core/component APIs in deployments that WildFly supports already. In other words, Camel should “just work” in standard Java EE deployments. The binaries are be provided by the platform. The deployment should not need to worry about module/wiring details.
Defining and Deploying Camel Contexts can be done in different ways. You either can directly define a Context in your standalone-camel.xml server configuration or deploy it as part of your web-app either as a single XML file with a predefined -camel-context.xml file suffix or as part of another WildFly supported deployment as META-INF/jboss-camel-context.xml file.
The WildFly Camel test suite uses the WildFly Arquillian managed container. This can connect to an already running WildFly instance or alternatively start up a standalone server instance when needed. A number of test enrichers have been implemented that allow you have these WildFly Camel specific types injected into your Arquillian test cases; you can inject a CamelContextFactory or a CamelContextRegistry as an @ArquillianResource.
Next Steps
You can simply undeploy the wildfly-camel.war and start over with your own application. You can either dig into the existing examples on GitHub or wait for my next blog-post to walk you through that a bit.
If you don't want to mess around with installing and patching, you can look at the ready available docker images which were published at wildflyext/wildfly-camel.
More Information
Apache Camel Website
WildFly Camel Integration GitBook
Planned Roadmap
