Enterprise Java

Camel Subsystem for WildFly 8 integrates Java EE – Getting Started

Just three days ago, the team around Thomas Diesler (@tdiesler) released the 2.0.0.CR1 version of the WildFly-Camel subsystem it allows you to add Camel Routes as part of the WildFly configuration. Routes can be deployed as part of JavaEE applications. JavaEE components can access the Camel Core API and various Camel Component APIs.

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.xml

Some 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.

 

Exploring What’s There

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.

hawtio-camel

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.

Markus Eisele

Markus is a Developer Advocate at Red Hat and focuses on JBoss Middleware. He is working with Java EE servers from different vendors since more than 14 years and talks about his favorite topics around Java EE on conferences all over the world. He has been a principle consultant and worked with different customers on all kinds of Java EE related applications and solutions. Beside that he has always been a prolific blogger, writer and tech editor for different Java EE related books. He is an active member of the German DOAG e.V. and it's representative on the iJUG e.V. As a Java Champion and former ACE Director he is well known in the community. Follow him on Twitter @myfear.
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Inline Feedbacks
View all comments
Back to top button