Teams in Fabric8

One of the first things you will probably do when starting to work with Fabric8 is the creation of a Team:

A team is a collection of people working together on one or more microservices.

A team has a number of environments such as Dev, Test, Staging, Production. Each team can decide whatever environments it requires. A team always has a Development environment where the development tools run such as Jenkins, Nexus and the developer console.

A team contains a namespace which must contain a Jenkins, Nexus and Gogs implementation in order to use the full benefits of Fabric8. However when you create a new team from the web console, you will notice that not everything is generated correctly. In the version of Fabric8 I was working with some parts where missing. The key components such as Fabric8 itself where not deployed in my namespace. This prevented the installation of the “CD-pipeline” which contains the Jenkins, Nexus and Gogs pods. After some research I found out that the workaround can be done from the command line. With the help of “kubectl”, the cli of kubernetes you first have to create a new namespace.

kubectl create namespace <namespace>
kubectl config set-context 'kubectl config current-context' --namespace=<namespace>
gofabric8 deploy

After the above commands have completed you will see a new namespace in your Fabric8 console. Select the “Create Team” button. Select the option “Existing Namespace” and pick the namespace you just created. Finish the installation of the team and you are ready to go.


When running the “CD-pipeline” installation I also ran into the persistence claim issue mentioned in the my previous blogpost. In order to create the persistence volume claims you have to specify the namespace as well. Otherwise the claims won’t be created.

gofabric8 volumes --namespace=<namespace>

Getting started with Fabric8

Last week I started to look into Fabric8. The first step I took, was of course the installation of Fabric8. This post is a short walk-through of my installation and the problems that I faced. You have several options for installing fabric8, as can be seen here. For simplicity I chose to install it on my Linux laptop (link). The installation of Fabric8 is quiet simple, I chose to install it with the KVM driver. When you are using Fabric8 you can easily create a lot of small applications. I noticed that the performance was not optimal when starting it with the default settings so I used the following command:

gofabric8 start --cpus=4 --memory=8144

After running the “gofabric8 start” command you will be redirected to your browser:
The first thing I tried to do was to create an application. The first time you do this Fabric8 will ask you to setup a Gogs Secrect. Just select the default entry “default-gogs-git”. Next fabric8 will ask you to run a CD pipeline. In order to create a new application Fabric8 requires several applications to be running in your domain. This includes Jenkins, Gogs and Nexus.
At this stage I found out that the installation was not completely successful. The Gogs, Nexus and Jenkins pods did not start correctly. It appeared that the latest version of kubernetes is not yet working correctly in combination with Fabric8. In order to get all the pods up and running I had to downgrade my kubernetes.

First stop your fabric8 instance and delete your minikube instance.

gofabric8 stop
minikube delete
minikube start --vm-driver=kvm --memory=8144 --cpus=1 --disk-size=50g --kubernetes-version v1.4.5
gofabric8 start

After this you will see that the pods are trying to start. However in my case they wouldn’t start correctly. I got the error:

StorageClass "standard" not found

The persistence claim could not be made. The claim is either not made correctly or not made at all. The solution is simple, you have to run the following command:

gofabric8 volumes

This command will create the persistence claims. When you go back to the Fabric8 console you will see that the pods will start correctly.

When you try to create an application you will no longer run into any problems. Complete the installation of the CD Pipeline and you can create your first application.

After that you can create a new Application. Fabric8 provides a list of example projects. I of course choose the integration (Camel with spring-boot) project).

Note that the current version of fabric8 dictates that you have to specify a project name with all lower-case. If you do not do this the project will only be partially created.


The next step is to select the pipeline you want to use. Default Fabric8 supplies several options, from a simple deploy to a complete Canary Release Stage and approval, which automatically creates a test, stage and production environment.


Just select your choice and sit back and wait until everything is created. You will notice that a maven job is triggered. The code of your application will be added to Gogs. If you go to the Jenkins instance of your instance. You will see that the Jenkins job has been created as well. After a while the first pod will be created the first (test environment). And, in my case, eventually a staging environment is created as well.


That is it, I have shown you how to install and create your first project in Fabric8. My first impression after the installation is that Fabric8 is not yet finished. The GUI feels a bit flaky, sometimes you have to hit the refresh button to see some data and not everything works out of the box. However, the options and potential that Fabric8 provides makes it an extreme interesting solution to run your applications. The out of the box provisioning, creation of environments, build-pipelines etc. look really promising.

Kafka with Camel

Kafka is a populair opensource, distributed streaming, platform which prides itself on key features as fault-tolerance and replay options. My colleague Jan van Zoggel wrote a nice “getting started” blog post about kafka which can be found here.

In this blogpost I will show you, in some very easy steps, how you can start producing and consuming kafka messages with apache Camel.

First of all you need to install Kafka itself ( After you have started the kafka service you need to create a topic.

bin/ --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic theBigKafkaTestTopic

When the topic is created you can start producing messages on the topic. Add the dependency to your pom file.


The following code snippet shows how to send a message to a kafka topic. Note that a header is set (KafkaConstants.KEY) this is the unique identifier for the kafka message.

 .setHeader(KafkaConstants.KEY,simple("bean:generateUUID?method=getGuid") )

Consuming can be done by adding the configuration url to your from component.


Contract first Rest API

As an integration consultant I have an extensive background in web services. To be specific SOAP enabled web services. The way I used to create a service was by first defining the contract, the WSDL and the XSD files. Based on those files I could generate a service without the need for me to manually type any code.

However lately I started working with Rest services, both JSON and XML. I have written a post (Rest just got easy) on how to create a service using the rest DSL from camel. However in some situations you might want to use a JAX-RS implementation, for example using CXFRS. This means you have to first create the interface definition using POJO’s. You could do this the manual way, like me in my first couple of implementations. Or you could generate the code based on an interface design (Hooray for the lazy!). In this blog post I will show you how to generate your rest interface implementation using swagger documentation (Swagger in a nutshell).

Using a maven plugin you can easily generate the required code based on a yaml styled swagger specification file. The plugin can be found through this dependency:


Because I am using CXFRS I added the dependency for that as well to my pom file:


After you have added the dependencies to the pom file you can configure the plugin.

		<!-- specify the swagger yaml -->
		<!-- target to generate -->

The plugin has several configuration options.

  • inputSpec – OpenAPI Spec file path
  • language – target generation language
  • output – target output path (default is ${}/generated-sources/swagger)
  • templateDirectory – directory with mustache templates
  • addCompileSourceRoot – add the output directory to the project as a source root (true by default)
  • modelPackage – the package to use for generated model objects/classes
  • apiPackage – the package to use for generated api objects/classes
  • invokerPackage – the package to use for the generated invoker objects
  • configOptions – a map of language-specific parameters (see below)
  • configHelp – dumps the configuration help for the specified library (generates no sources)

As you can see in my example I specified the language to be “jaxrs-cxf”. Meaning that the generated sources will be specific for jaxrs-cxf. The modelPackage will contain the actual objects. If specified the plugin will add the XML declarations to the model POJO’s. The apiPackage will contain the interface specifications.

Create the yaml file on the specified location. My yaml file looks like this:

swagger: '2.0'
  version: 0.0.0
  title: Simple API
          description: OK

Meaning, a very simple interface that listens to the root (“/”) of servic epath and will return a http 200 if everything went as planned.

Now that the configuration is done, you can generate the sources with “mvn compile”. You will see the generated sources in the packages you specified.

If everything went correct you can now specify your service. In my example I am using blueprint in combination with the java DSL.

The blueprint definition for the cxfrs component:

<cxf:rsServer id="api" address="http://localhost:9092/test"
     <bean class="org.apache.cxf.jaxrs.provider.json.JSONProvider" />

And the route configuration:

from("cxfrs:bean:api?bindingStyle=SimpleConsumer").log("you did it!");

My example project can be found here: Download sources

Basic authentication in Camel

I need to call a webservice that uses basic authentication. All the solutions and suggestions I could find via google where ether complicated or a lot of work. Until I looked at the CXF manual ( As of version 2.12.3, you can do it by simply adding the username and password to your endpoint in your camel route.


JBoss Fuse on a raspberry pi 3

I was looking for a small server to run my personal fuse installation on. After a quick search I found the raspberry Pi as a likely candidate. A cheap and energy efficient device. Although it runs on an ARM processor you can run a (ARM) JDK on it. Which allows you to run a Jboss server and thus a Fuse server.

First install an operating system on your Pi. I chose Raspbian (lite), because of its simplicity and the fact that is a Debian distro, which I like. You can get the latest here. Installing it is simple and the site provides a good installation guide.

After the installation you want to add an usb drive or an external HDD. The SD is required for the installation of your OS but it is not wise to install the rest of your software on the SD card. More information about this can be found here. Make sure that your drive is correctly formatted (for example ext4). Check the location of your drive and (auto) mount it via editing fstab.

sudo fdisk –l 
sudo vi /etc/fstab
/dev/sda1		/apps		ext4	user,exec	0	1

After rebooting your pi confirm that the mount has succeeded. When you run “mount -l” you should see the “/dev/sda1/” mounted on the “/apps” location. Change the access rights to the directory with “sudo chown pi:pi /apps”. Note that if you made a mistake you can no longer reach your pi with ssh. It will be started in “safe mode”. You have to access the pi directly and fix the problem.

Now you are all set up to install the JDK and Fuse. Because the raspberry pi has an ARM processer you cannot install the usual JDK. You have to install one for the ARM processor, you can find the installer here.

The installation is quite straightforward, after you have unzipped the JDK you have to set the java version. This can be done in the .profile file.

vi ~/.profile
export JAVA_HOME=&lt;locatie&gt;
export PATH=$PATH:$JAVA_HOME/bin

Conferm that java is working (java –version).

Install the fuse server (installation guide).

The last step is simple, start the fuse server. Mind that it will take a while before it is started, especially the first time.

Rest just got easy

As of version 2.14 camel supports an easy alternative for the implementation of rest interfaces, RedHat implemented it in Fuse 6.2 You can now use the rest DSL as an alternative for CXFRS. This means you no longer have to define the interface in a separate class. With the rest DSL you can specify the interface definition inside the route builder itself. This means that you can link your rest interface directly to your camel route implementation. No extra injection etc. is required. You can have a rest interface up and running in just a few easy steps. In this blog post I will describe these steps and some extra options you might find useful.

The code I use in the examples can be found here. I have used blueprint in combination with the java DSL.

The rest DSL is similar to the standard DSL you use when defining your camel routes. The configuration globally consists out of two factors. First there is the rest configuration.
In the configuration part you tell which Camel component you want to use to host your rest service. This component will handle the actual rest transportation. For my example I used the jetty component.

Besides the camel component you have to configure some other stuff. The most important ones are listed below:
• host – the location on which the endpoint needs to be hosted;
• port – the port on which the endpoint is hosted;
• bindingmode – dictates the way the input of the rest calls is binded / mapped. Here you can specify that a post method with a specific type must be cast to the corresponding pojo. In my example I set it to JSON. This means that the JSON input is mapped to the pojo automatically.

	.dataFormatProperty("prettyPrint", "true")

The second part of the rest configuration is the interface definition. Here you will see the biggest advantage when using the rest DSL.

Normally you start a camel route with a simple “from()”, using the rest DSL you start with “rest()”.

The first thing you can set in the interface is the path on which your interface can be found. After that you can define your methods. The rest DSL supports the standard rest methods (post, get, delete etc.)


	.log("body: ${}"

When defining a post operation you have the possibility to define the input type. By setting the POJO as the input type you can automatically cast (bindingmode) the input (json or XML) to the POJO class.

When defining an operation you have two options. You can either use the route functionality inside your rest definition or you can use the to() method to call another route. By calling another route you separate your interface definition from the orchestration which keeps your code clean.

Camel RestDSL documentation

Calling a Soap Service with camel

Invoking a SOAP service in Fuse (camel) is similar to exposing a SOAP service. The first steps are the same, you have to create a CXF endpoint. This is explained in full in this blogpost.

You first generate the source classes based on the WSDL. After that you register it as a CXF endpoint in (in my case) the blueprint file of your project. The main difference is that you need to specify the address / endpoint of service.

<cxf:cxfEndpoint id="newOrderEndpoint"  

Calling the service from your route can be done by simply setting the CXF endpoint in your “to” statement.


If you would now call the service, CXF would choose the first operation in the WDSL. So we have to tell CXF which operation it needs to call. This is done by setting the header “OperationName”. This header will tell CXF to call the operation you want.

.setHeader("OperationName", simple("getTheSpecialOrder"))

The last part is creating the body for the request message. One way to do this is in a processor. In my case the code looks like this:

ObjectFactory objFac = new ObjectFactory();
GetTheSpecialOrderRequest requestMsg = objFac.createGetTheSpecialOrderRequest();

If everything is set correctly you should be able to call the service. In order to test it properly I created a mockserver in SoapUI. Which is included in the sources of this project (project sources).

Removing camel HTTP Headers

When trying to invoke a json rest service from a route in my CXF soap web service using HTTP4. I got the following error:

“If you are forwarding/bridging http endpoints, then enable the bridgeEndpoint option on the endpoint:”

It appeared that camel was trying to send more information then required. This because CXF uses / generates some HTTP headers. These headers are fine for CXF but when using HTTP4 it gave me the error.

In order to solve this I stumbled upon this post of RedHat.

By simply removing all the camel HTTP headers I was able to successfully call my json service. You can remove the headers with the following statement in your route:


Fuse contract first webservice

In this blog post I will explain how you can create a SOAP web service in Fuse. You can implement a SOAP interface with the help of CXF. Creating a soap web service with CXF can be done in two ways, contract first or code based. Code based means that the contract is based on the java code. Contract first means that you first specify the contract (WSDL, XSD) and base the implementation on that contract. Because contract first gives you complete control over the interface contract I think it is the best way to go.

In this example I have chosen to use blueprint in combination with the java DSL.

So the first thing, and in my opinion the hardest part, is creating the WSDL. You can find mine and the sources of the project (and the WSDL) here.

The next thing you need to do is generate the code based on the WSDL. This is done with mvn. By adding the following snippets to your pom.xml file mvn will generate the java code that represents the WSDL.

First add the CXF dependency:

     <version><your camel version></version>

Add the plugin that generates the java source code for the contract. Make sure it points to the location of your WSDL and that the WSDL is inside the package:


After these changes are made you have to run “mvn generate-sources” in order to generate the sources. After this is done, you will probably need to update your project inside your IDE. Otherwise you might not see your generated sources in the project structure.

After the sources have been generated you can add the endpoint to the blueprint of your project. Do not forget to add the CXF namespace. By specifying the endpoint inside your blueprint you can later use it inside your route.

<cxf:cxfEndpoint id="newOrderEndpoint"  address="/newOrder/"  serviceClass="nl.rubix.service.neworder.NewOrderServiceOperationsPortType">

Now you are ready to create your endpoint in the camel route. Add the following statement to your route (in my case the java dsl), it should look like this:


If you want to see the results of your work you could deploy the bundle to your server. After this is done you should be able to see the service (and the contract) listed at http://localhost:8181/cxf.

Now that the configuration things are done we can actually start implementing the service. The contract in this example specifies two operations with, for the case of simplicity, the same response (xsd element). So we need to change the route so that it can process the two operations.

One way of doing this is by using the recipientList. This allows you to dynamically call another route. If you base the recipientList on the operationName header camel will send the message to the corresponding route.   All the HTTP / SOAP headers are accessible in the route so it is quite straightforward.

.log("operation: getTheOrder")

.log("operation: GetTheSpecialOrder")

Each operation in a WSDL normally has a different implementation behind it. Within Fuse I solved it by creating sub routes and for each operation a separate processor. By adding the subroutes you can create specific orchestration per operation. For example call a different database procedure or underlying web service.

The final piece of the puzzle is of course the transformation of the input message and generating the output message. In this case I made a stub that maps part of the input message to the output message. This is done in the processors.

Accessing the input message in the processor can be done in one statement. The generated code contains the class that specifies the input message of the operation. In this case the GetOrderRequest.class. The only thing that you need to do is casting it to the right class. This can be done with the following statement:

GetOrderRequest input = exchange.getIn().getBody(GetOrderRequest.class);

In order to create the output message you can also use the classes generated by CXF. If everything has been generated successfully you should have an ObjectFactory class with which you can generate the output. I mapped the input to the output (OrderNumber) and made sure the generated XML was conform the contract specifications.

ObjectFactory objFac = new ObjectFactory();
GetOrderResponse outbody = objFac.createGetOrderResponse();
CustomerType newCustomer = new CustomerType();
OrderType order = new OrderType();
OrderListType newOrderList = new OrderListType();


After this is you only have to pass the output message back to CXF:


Generate a similar processor for the other operation and you are done. Deploy the service to the server and test it (for example, with soapUI).

Read More »