How to centralize Camel & ActiveMQ configuration in fabric8 registry


In my above article, we saw through a use case how to take advantage of traceability in a fully distributed architecture [link].

In this article, we will see in the same context, how we can take advantage of fabric8 registry by centralizing the configuration of the whole Camel routes and ActiveMQ.


As shown in the diagram above, all camel routes and ActiveMQ Broker in JBoss Fuse retrieves their configuration data in the Fabric8 registry, such use has allowed to:

  • Centralize all configuration data in one place, which makes the operation simple and trivial.
  • Distinguish the configuration data for different environments: Dev, Test, qualif & Prod.
  • Automate the creation and update of the configuration data.
  • Encrypt all credentials configuration. (No password is visible in the cfg files)

Let’s start an example to see how it works:

First we should install the ‘zookeeper-commands’ feature:

In fabric8 features are also controlled by fabric8, for this reason the good old ‘feature:install’ command will not work.

I resulted in installing the zookeeper-commands feature through the Hawtio console.

In the Hawtio console go to ‘Wiki’ → edit fabric features → search for zookeeper and select zookeeper-commands → click the ‘Add’ buttom and finally click ‘save’


Now, we can find all the zk commands on the console:

JBossFuse:karaf@root> zk:
zk:create    zk:delete    zk:edit      zk:export    zk:get       zk:import    zk:kill      zk:list      zk:set

Example of camel route configuration:

In this camel route, we have used the fabric registry for 2 reasons: centralize camel configuration, and the recipient list lookup.

Below part of this route camel:

All variables defined in the route camel, will be substituted with the contents of a ZooKeeper node using the zk URL. The cfg file resulting to this route will be like:

Using ZooKeeper commands, we will execute the following commands to create initial configuration in fabric8 registry:

With these elements, the route camel became pretty simple. On startup, it retrieves basic initialization configuration data from fabric8 registry.

The same idea has been applied for activemq configuration, by externalizing the common configuration, like regarding destination policy, because the most time we apply the same policy in all brokers, like the prefix or the suffix for DLQ, or discarding expired messages.

I hope that this post will give you an idea about the different possibilities that are offered by fabric8.

If you-have any questions, feel free to ping me via twitter @a_bouchama.


Abdellatif Bouchama

Abdellatif's main area of expertise lies within the fields of SOA, ESB, BigData and IoT.

You may also like...

2 Responses

  1. Hi, this approach is interesting but it has a limit:

    blueprint deployer will not notice Zookeeper updated entries.

    To let your deployments pick that up you need to trigger a bundle update or restart.

    Instead, if you use traditional OSGi ConfigAdmin integration, or its extension provided by Fabric8/JBoss Fuse Profiles mechanism, you will have bundles able to react to configuration modifications and able to see updated values without requiring you an explicit restart of your deployment units.

    • Hi Paolo, I agree with your approach,

      In this case, the operation guy want to schedule the refresh or the update camel flows manually, in order to reduce the down time.

      Thanks for sharing your approach again, it is very interesting.

Leave a Reply to Abdellatif Bouchama Cancel reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>