Setting up a restlet with Camel in JBoss Fuse

If you have already successfully gone through the steps of the previous tutorial, this is going to be quite fast and straightforward. All you need to know is that in Camel you can set up a restlet to listen to a specific URL/port with the “restlet” prefix.

Let’s assume that we want to listen for REST request and turn the body of the request into a message to be queued on one of our (already existent) ActiveMQ. As in the previous example, we can accomplish the task without even write a line of Java code.

We can add the following elements to our blueprint.xml file:

        <from uri="restlet:http://localhost:8282/demo-endpoint?restletMethod=POST"></from>
        <log message="The request body is: ${body}"></log>
        <to uri="activemq:sink-queue" pattern="InOnly"></to>
        <to uri="mock:result"></to>

Here I’m specifying the restletMethod parameter, which tells Camel to only respond to GET HTTP request (i.e. any other HTTP verb will result in the request to be discarded). The setBody element is used for making thigs simpler: it sets the body of the exchange to the child value, as you might expect. Now we can “clean-install” the project as usual and switch to the Karaf console. Update the package with a osgi:update command (here, 251 is the ID of my bundle, you will probably have a different one. You can find out what ID your bundle has by executing a “list” command):

JBossFuse:karaf@root> osgi:update 251

After this, execute “list” and take a look at the output. In correspondence with the updated bundle you should see something like this:

[ 251] [Active     ] [GracePeriod ] [       ] [   60] A Camel Blueprint Route (1.0.0)

This is because the bundle has a missing dependency: the camel-restlet Feature. The bundle has been successfully installed, but it cannot be started until the missing dependency is satisfied. The missing feature is not installed by default in Fuse. Luckily, you can easily get it by typing the following command:

JBossFuse:karaf@root> features:install camel-restlet

To learn more about Features, refer to the official documentation.

Restart your bundle. The restlet is now ready. You can try and call it with whatever method you prefer. For simplicity, i present you the command used to perform a test with curl:

curl --data "test=true" http://localhost:8282/demo-endpoint



JBoss Fuse installation tutorial

At work I was given the task to study JBoss Fuse and become sufficiently comfortable developing and deploying basic projects on this platform. I’m going to write a series of post to share my experience and considerations.

Some random thoughts

I’m not going to rigorously explain you what Fuse actually is. But if you start from scratch, without any previous knowledge of a Service Bus middleware, it’s quite hard to get the essence of the system. And if you try to make an idea through what you find online, good luck. It’s hard to find something that tells you what you can really use Fuse for, possibly with some insightful examples. In fact, it is almost impossible. Sure you can find some “case studies” or articles that tell you how good Fuse is at integrating systems and how big a shitload of money they saved by using it instead of, say, building a similar monster from scratch. But those are only marketing mumbo jumbo and do not give you any useful tip on the technical side of the matter, which is what I really care about. What help me the most in these cases is bringing it down to a very trivial use case description and a set of practical examples. And this is what I am trying to do here.

Fuse is huge, very huge. It is a collection of subsystems taped together by Karaf, an OSGi container developed by the Apache Foundation. Here are only some of the subsystem included. I only knew the name of most of them until now, and some were completely unknown:

  • Karaf,
  • Camel,
  • CXF,
  • Hawtio,
  • Felix,
  • ActiveMQ,

JBoss Fuse is basically a Service Bus, a middleware, that allows you to host services and integrate a wide variety of heterogeneous systems. But this is not very helpful. So, this is the picture that I have after spending several hours using Fuse and developing tutorial and demo projects: if you have, say, a desktop application developed for Windows, a bunch of Web Services hosted in Tomcat in a Linux box, an external database that needs somehow to be updated and you want to let this system talk to each other, then Fuse might be the way to go. You can set up a Web Service in Fuse (REST or SOAP doesn’t matter) and use Apache Camel to connect the various pieces in a so called “route”. There already are a lot of components that automagically let you call an external web service, read and/or write to a database, reading or write a text file over FTP, reading or writing a directory over LDAP and whatnot. Here is a list of what is available. I particularly enjoyed the SSH connector and I’m looking forward to give it a try in a real project.

Another possible scenario is an Enterprise application that needs to interface with a legacy system. Think about an organization that wants, for some reasons, a new, cool, bleeding edge, good looking front end to amaze and fool the customers, but does not want to get rid of its 30-year-old COBOL code base running on IBM mainframes (nobody wants to do that). You can use Fuse to translate messages (from XML/JSON to plain text and back again), decouple the systems by using queues, log, and so on. Again, this is how I currently picture Fuse in my mind, I do not claim to give you a full coverage of the possible, numerous use cases.


Finally. Fuse is as easy to install and launch as Liferay, Alfresco and Pentaho (just to name few that I recently had to install). Even easier, in a sense. That is what you expect, since it’s completely Java based. Just unpack the tarball or the zip archive and launch <FUSE_DIR>/bin/fuse or <FUSE_DIR>\bin\fuse.bat, depending on what OS you are on. Keep in mind that the current release of Fuse (6.0.1) requires Java 7 and does not support Java 8. If you have your JAVA_HOME environment variable set to something different, you have to change it by either editing /etc/environment or the startup script. To do the second, which I recommend, Open the “<FUSE_DIR>/bin/karaf” script and add the variable definition, just like this:

#explicitly sets the value of JAVA_HOME to a compatible JDK

DIRNAME=`dirname "$0"`
PROGNAME=`basename "$0"`



Now run the script named fuse and, if everything is OK, the Karaf console starts showing a prompt like the following:


The first thing that we want to do is to create an administrative user in order to access the Web console. So type:

JBossFuse:karaf@root> esb:create-admin-user

And there we go, we can now open a browser and navigate to http://localhost:8181, and have full access to the management web application.

Easy deployment made hard

I recently started “evaluating” OpenShift, the fanta-mega-giant cloud offer by Red Hat. OpenShift basically offers you what most so called cloud services offer today: virtual servers that you can remotly manage with a certain degree of autonomy. What took me to OpenShift was the fact that I was searching for a way to host a Java EE web application, possibly with a free basic plan. My initial idea was to find a provider of a simlple Tomcat 7 or 6 and a basic way to upload a WAR file. This requirement has turned out to be surprisingly hard to meet. So long, OpenShift has been the only platform to be able to satisfy me but it has been anything but easy to achieve.

OpenShift is capable of hosting a vast range of applications, spanning from PHP to Ruby On Rails, with almost anything you can imagine in the middle. One of the options is JBoss EWS, a profile that is able to host Tomcat which, in turn, can contain your applications.

Once you have your account you are in Red Hat territory and you have to follow their rules. It can take quite a long time to get started, especially if it is the first time that you do that. First, you have to install on your machine a lot of stuff to enable the development tools necessary to upload the applications and manage the server. Note: you have to install stuff to be able to install the OpenShift tools. Once you are done with Ruby, ssh and the rhc utility, you can create an application and start coding.

The basic configuration of the application is decided by OpenShift: you choose the name, OS choose all the rest. It creates a remote Git repository with a directory tree for your project and a Maven pom file for managing the build process. Now, if you have not already given up, you can clone the project and start coding on your dev machine. So OS gives you anything: a Git repo, an application server for deploying, a build process and a standard directory structure for your source files. Whenever you want to deploy your application remotely, you can do a “git push”: the server will automaticaly recognize the changes, start a build and, if anything goes right, deploy the resulting war. Seems easy, doesn’t it? Nop.

OS gives you much. It actually gives you too much. What if I have a preexistent project, possibly connected with another repository, and with dependencies from other projects? I just want to deploy the fucking war and see what happens, ok? I don’t what to spend three hours trying to figure out how I can map it all on the project created by OS. And I am sincerely thankful, OpenShift, for your commitment in making me aware of the advantages of continuous integration, but I just wanted to deploy the war, please.

I finally figured out that this is the answer to all my problems. The only thing is: you better read all the thread, because the final post is foundamental: you have to tell JBoss to unpack the war.