Red Hat Training

A Red Hat training course is available for Red Hat Fuse

18.2. The Apache Camel NMR Component


The NMR component is an adapter to the NMR, enabling Apache Camel applications to send messages to other bundles within the OSGi container or to components within the JBI container.

Installing the NMR feature

Normally, the NMR feature is pre-installed in the OSGi container. If you need to install the NMR feature, however, you can do so by entering the following console command:
JBossFuse:karaf@root> features:install nmr

Instantiating the NMR component

To make NMR endpoints available to your Apache Camel application, you need to create an instance of the NMR component. Add the code shown in Example 18.1, “Creating the NMR Component Bean” to your bundle's Blueprint configuration file (located in OSGI-INF/blueprint/*.xml) in order to instantiate the NMR component.

Example 18.1. Creating the NMR Component Bean

<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns=""
    <reference id="nmrservice"

    <bean id="nmr" class="org.apache.servicemix.camel.nmr.ServiceMixComponent">
        <property name="nmr" ref="nmrservice"/>

The bean element creates an instance of the NMR component with the bean ID, nmr, where this bean ID can then be used as the scheme prefix to create or reference NMR endpoints in your Apache Camel routes. The bean definition references two external Java packages—org.apache.servicemix.camel.nmr and org.apache.servicemix.nmr.api—which must therefore be imported by this bundle. Because the packages do not occur in Java source code, you must add them explicitly to the list of imported packages in the bundle instructions in the POM—see the section called “Configuring the bundle instructions” for details.

URI format for the NMR component

The NMR component enables you to create endpoints with the following URI format:
Where EndpointId is a string that identifies the endpoint uniquely. In particular, when used within the OSGi container, the endpoint ID string is not restricted to have any particular format. The scheme prefix, nmr, is actually determined by the ID of the bean that instantiates the NMR component—for example, see Example 18.1, “Creating the NMR Component Bean”.

Addressing JBI endpoints

If you want to use the NMR component to send messages between the OSGi container and the JBI container, you need to be aware that NMR endpoints inside the JBI container requires a special syntax for the endpoint IDs. You can address an NMR endpoint inside the JBI container using the following URI format:
Where JBIAddressingURI conforms to the URI format described in ServiceMix URIs.

Determining the message exchange pattern

An NMR consumer endpoint automatically determines the message exchange pattern (for example, In or InOut) from the incoming message and sets the message exchange pattern in the current exchange accordingly.

camel-nmr demonstration

The camel-nmr demonstration is located in the following directory:
The demonstration defines two routes in XML, where the routes are joined together using an NMR endpoint, as follows:
  1. The first route is defined as follows:
    1. At the start of the route is a timer endpoint, which generates a heartbeat event every two seconds.
    2. At the end of the route is an NMR endpoint, which transmits the messages to the next route.
  2. The second route is defined as follows:
    1. At the start of the second route is an NMR endpoint, which receives the messages sent by the first route.
    2. Next comes a callout to a transformer bean (implemented in Java), which transforms the hearbeat into a message containing the current date and time.
    3. At the end of the route is a log endpoint, which sends the transformed message to Jakarta commons logger.
The route is deployed into the Red Hat JBoss Fuse container as an OSGi bundle.

Defining the route in a Blueprint XML file

Example 18.2, “Blueprint XML Defining a Route with an NMR Endpoint” shows the routes for the camel-nmr demonstration, taken from the Blueprint XML configuration file, OSGI-INF/blueprint/beans.xml.

Example 18.2. Blueprint XML Defining a Route with an NMR Endpoint

<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns=""
    <reference id="nmrservice"

    <bean id="nmr" class="org.apache.servicemix.camel.nmr.ServiceMixComponent">
        <property name="nmr" ref="nmrservice"/>

    <bean id="myTransform" class="org.apache.servicemix.examples.camel.MyTransform">
      <property name="prefix" value="MyTransform"/>

    <camelContext xmlns=""
        <!-- Route periodic events into the NMR -->
            <from uri="timer://myTimer?fixedRate=true&amp;period=2000"/>
            <to uri="nmr:ExampleRouter"/> 1
        <!-- Route exchange from the NMR endpoint to a log endpoint -->
          <from uri="nmr:ExampleRouter"/> 2
          <bean ref="myTransform" method="transform"/>
          <to uri="log:ExampleRouter"/>

At the end of the first route, messages are sent to the NMR endpoint, nmr:ExampleRouter.
When you specify an NMR endpoint in the uri attribute of the <from> tag, a new NMR endpoint is created by the NMR component. In this example, the <from> tag implicitly creates the NMR endpoint, nmr:ExampleRouter, which is then capable of receiving the messages sent by the first route.

Configuring the bundle instructions

Not all of the packages required by the NMR component can be automatically detected by the Maven bundle plug-in. Some of the package dependencies arise from settings in the Blueprint configuration file (see Example 18.1, “Creating the NMR Component Bean”), which are not automatically taken into account by the bundle plug-in. In particular, you must ensure that the following additional packages are imported by the bundle:
  • org.apache.servicemix.camel.nmr
  • org.apache.servicemix.nmr.api
For example, the following sample configuration of the Maven bundle plug-in shows how to add an Import-Package element that contains a list of the packages required for the NMR component:
<project ...>

The Import-Package list also includes the wildcard, *, which instructs the bundle plug-in to scan the Java source code in order to discover further package dependencies.