Red Hat JBoss Fuse ESB + Top 100 Interview Questions & Answers (2023 Update)

Here are Red Hat JBoss Fuse ESB interview questions and answers for fresher as well as experienced candidates to get the dream job.

Table Of Contents
 [hide]

1. What is Red Hat JBoss Fuse ESB?

  • Fuse combines various technologies together as a single product.
  • Like all the other JBoss products, Fuse is also a platform independent zip.
  • Red Hat Fuse is an open source integration platform based on Apache Camel. It is a distributed integration platform that provides a standardized methodology, infrastructure, and tools to integrate services, microservices, and application components.
  • Red Hat Fuse supports Spring Boot, OSGi and Java EE for use in enterprise IT organizations. It has a pluggable architecture that allows individuals to use their preferred software services in a traditional service-oriented architecture (SOA) or a microservices-based architecture. Fuse components may be deployed on-premises or in public/private clouds.
  • JBoss Fuse is an OSGi container in simple words.
Fuse 7 architecture
  • Apache Camel still is the core component in Fuse.
  • Narayana is now the transaction technology, to get you ready for handling more-complex distributed transactions.
  • Jetty is deprecated and replaced by a more streamlined, lightweight web container: Undertow.

2. What are the components of JBoss Fuse?

The following are the components of Red Hat Jboss Fuse.

Fuse Components
  • Apache Camel
  • Apache CXF
  • Apache ActiveMQ
  • Apache Karaf
  • Fabric
  • Switchyard
  • Apache Camel: Apache Camel is a EIP based integration framework. EIP or Enterprise Integration patterns are identified solutions to the recurring problems in Enterprise Integration. Complete integration solution can be achieved meteorically with combinations of these pre-defined out of the box patterns. It allows to write routing logic in several Domain Specific Languages like Java, Spring DSL, and Scala etc.
  • Apache CXF: Apache CXF is a fully-featured Web services framework. It is built with a combination of Celtix and XFire. It is the building block for JBoss Fuse’s embedded Web and RESTful services framework. To create reusable web services, Apache CXF offers a small footprint engine. It permits Code-first or Contract-first improvement with JAX-WS.
  • Apache ActiveMQ: Apache AMQ is a JMS which provides reliable messaging system as per JMS standards. It not only support JMS specification but also provides some exciting and useful features which are not included in JMS specifications.
  • Apache Karaf: Apache Karaf is lightweight OSGi container which acts as runtime for the artifacts. Apache Karaf is more dynamic in nature as compared to JVM. It allows to install or uninstall modules at runtime. All the artifacts in Fuse are deployed in Karaf.
  • Fabric: Fabric provides easy way to manage deployments of artifacts in a large and distributed environment. It provides centralized management for all multiple fuse instances.

3. Why do you need to have so many different options for runtime in Fuse?

It’s because we believe developers should be able to choose what best suits them, for example:

  • Karaf 4 for OSGi lover
  • Red Hat JBoss Enterprise Application Platform for Java EE developers
  • Spring Boot for microservices architecture support

4. What are the key features of RedHat JBoss Fuse ESB?

  • Hybrid deployment – use Red Hat Fuse on-prem, in public/private clouds, or as a hosted service and have all integration infrastructure work seamlessly allowing users to collaborate across the enterprise.
  • Distributed infrastructure – Integrations, built from predefined Enterprise Integration Patterns (EIPs) and over 2000 connectors, are deployed on container-native infrastructure to adapt easily and scale quickly.
  • Low-code interface – tooling allows developers and non-technical users to drag and drop predefined services and integration patterns so business units can self-serve and continuously innovative.

5. What are the deployment options in RedHat JBoss Fuse ESB?

We can go with following deployment options:

  • Fuse Standalone – for on-premises deployment.
  • Fuse on OpenShift – deployed in a public or private cloud on Red Hat OpenShift where containers are automatically provisioned and managed.
  • Fuse Online – fully hosted with a browser based, drag-and-drop UI/UX to create and deploy integrations.

6. After you extract the JBoss Fuse (standalone) folder, what directories will be there in it?

JBoss Fuse consists of the following directories.

  • bin
  • etc
  • deploy
  • lib
  • fabric
  • licenses
  • extras
  • quickstarts
  • system
  • patches etc.
Redhat Fuse Directory Structure

7. How many connectors are offered by the Fuse ESB?

JBoss Fuse provides more than 200 connectors that are ready to use for supporting Integration everywhere. It supports integration for the extended enterprise, including applications and services on-premise, or in the cloud, or on mobile devices. Users can connect from legacy systems to Software-as-a-Service (SaaS) applications, and application programing interfaces (APIs) to Internet of Things (IoT) devices.

8. What is SwitchYard?

SwitchYard is a lightweight service delivery framework on top of JBoss Fuse. It provides full lifecycle support to develop, deploy, and manage Service-Oriented Applications. It works with Apache Camel along with comprehensive connectivity and transports to provide a fast, simple, flexible integration runtime.

9. What is the importance of Apache Karaf in JBoss Fuse? How it is differ from Docker?

Apache Karaf is a powerful OSGi-based runtime container to deploy and manage bundles. JBoss Fuse uses Apache Karaf as the runtime. It is where the application bundles run. Apache Karaf is built on top of OSGi Frameworks like Felix and equinox. While Docker is an open platform that enables developers and system administrators to create distributed applications.

The main advantages / disadvantages for these styles are the same as monolith vs. microservice architecture. I’ve used both extensively and they solve different problems. In short: OSGi Apache Karaf can help you build an application which is modular but in the end (no matter how many or little modules used) still runs in a single JVM process. Docker can help you to manage the deployment of an application which often helps if your solution is architected as a microservices (a whole bunch of separate processes) and run into multiple JVMs.

10. What is OSGi?

OSGi (Open Service Gateway Initiative) is a Java framework for developing and deploying modular software programs and libraries.

OSGi has two parts. The first part is a specification for modular components called bundles, which are commonly referred to as plug-ins. The specification defines an infrastructure for a bundle’s life cycle and determines how bundles will interact.  The second part of OSGi is a Java Virtual Machine (JVM)-level service registry that bundles can use to publish, discover and bind to services in a service-oriented architecture (SOA).

In simple words the OSGi technology is a set of specifications that define a dynamic component system for java. These specifications allow a development model where applications are (dynamically) composed of many different (reusable) components.

Benefits of OSGi java framework:

  • Reduced Complexity − Application is built as collaborating components which hide their implementation details from each other resulting in reduced complexity.
  • Reusability − Many components can leverage same component deployed in a container.
  • Deployment − OSGi provides support for start, stop and update of components on the fly with its lifecycle management APIs without container restart.
OSGi Framework

The JVM Problem: JVM or Java virtual Machine does not act as an actual virtual machine. A machine which will allow you to stop, start or restart components running inside it on the fly. It may sometimes allow hot deployments at class level but there is no way you could deploy or undeploy a component of your application in your virtual machine without restarting it. To solve this problem and allow modularity in Java application, Fuse uses an OSGi based runtime known as Apache Karaf.

Apache Karaf is an OSGi based runtime, it is where our Application bundles run. Fuse uses Apache Karaf as its runtime in which bundles run and collaborate to provide business functionality.

Karaf is built on Felix and equinox which are OSGi Frameworks.

Karaf Architecture

Apache Karaf adds the following additional functionalities to basic OSGi runtime.

Hot Deployment

Karaf supports hot deployment. It contains a hot deploy directory. Anything that is placed in this directory is automatically deployed and installed in Karaf as a bundle.

Logging

Karaf provides centralized logging by generating logs for all bundles in $Fuse_home/data/log. We can edit logger configuration in org.ops4j.pax.logging.cfg in $Fuse_home/etc directory.

Admin console

Karaf provides a sophisticated and lucid Admin console to interact with running instance of fuse. It also provides a pre-installed set of commands which can be used to manage and monitor components (Bundle) at runtime. This console is extensible so it allows us to add new commands to the console by adding new bundles to console.

SSH Access

Karaf allows remote access to this Admin console with SSH. Anyone with valid credentials can connect to karaf admin console over SSH terminal.

12. How is the application deployed as Bundles?

This is achieved by using the Apache Felix Plugin. For step by step guide: Red Hat JBoss Fuse ESB + Apache Camel + ActiveMQ + OSGI Blueprint DSL + Example

13. What do you mean by Bundle Lifecycle Management?

Applications in an OSGi environment are subject to the lifecycle of its bundles.
Bundles have six lifecycle states:

OSGi bundle states
  1. Installed — All bundles start in the installed state. Bundles in the installed state are waiting for all of their dependencies to be resolved, and once they are resolved, bundles move to the resolved state.
  2. Resolved — Bundles are moved to the resolved state when the following conditions are met:
    • The runtime environment meets or exceeds the environment specified by the bundle.
    • All of the packages imported by the bundle are exposed by bundles that are either in the resolved state or that can be moved into the resolved state at the same time as the current bundle.
    • All of the required bundles are either in the resolved state or they can be resolved at the same time as the current bundle. If any of the above conditions ceases to be satisfied, the bundle is moved back into the installed state. For example, this can happen when a bundle that contains an imported package is removed from the container.
  3. Starting — The starting state is a transitory state between the resolved state and the active state. When a bundle is started, the container must create the resources for the bundle. The container also calls the start() method of the bundle’s bundle activator when one is provided.
  4. Active — Bundles in the active state are available to do work. What a bundle does in the active state depends on the contents of the bundle. For example, a bundle containing a JAX-WS service provider indicates that the service is available to accept requests.
  5. Stopping — The stopping state is a transitory state between the active state and the resolved state. When a bundle is stopped, the container must clean up the resources for the bundle. The container also calls the stop() method of the bundle’s bundle activator when one is provided.
  6. Uninstalled — When a bundle is uninstalled it is moved from the resolved state to the uninstalled state. A bundle in this state cannot be transitioned back into the resolved state or any other state. It must be explicitly
    re-installed.
    The most important lifecycle states for application developers are the starting state and the stopping state. The endpoints exposed by an application are published during the starting state. The published endpoints are stopped
    during the stopping state.

14. What are the basic configuration of JBoss Fuse? How we can configure the maven repo in JBOss Fuse?

We will discuss about the basic configuration of JBoss Fuse and for that we have to start with the following command Edit $FUSE_INSTALLATION_DIR/etc/

  • In user.properties
    • #admin=admin,admin
    • This needs to be changed according to the first admin with username we want, second admin with password, third one might be kept as it is because it indicates a role and don’t forget to remove #
    • For example – FuseAdmin = FusePass,admin
  • In System.properties
    • karafName = root
      • This indicates the name you want to give to Karaf instance.
      • We can name it anything we want like Cont1.
      • Make sure this name you give is unique name and not already being used by another instance of Fuse.
  • In org.ops4j.pax.web.cfg
    • org.osgi.service.http.port = 8181
    • This property indicates the port that is to be used for accessing browser-based interface HAWTIO provided by Fuse
    • HAWTIO is an in-built browser interface to Fuse which is available from 6.0 onwards
  • In org.ops4j.pax.url.mvn.cfg
    • org.ops4j.pax.url.mvn.localRepository = D:/repository
    • This property indicates the path to localRepository of our Maven from where Fuse will install its artifacts.
    • org.ops4j.pax.url.mvn.settings = D:/Maven/conf/settings.xml
    • This property indicates settings.xml which Fuse should use to get artifacts from Maven.

15. Explain the deployment models of JBoss Fuse?

There are three types of deployment models in JBoss Fuse.

  • OSGi bundle deployment model – A bundle shares all the required dependencies, which minimize resource consumption. 
  • FAB deployment model – The metadata will be embedded into the FAB. The JBoss Fuse container analyzes the metadata and automatically installs the requisite dependencies from Apache Maven.
  • WAR deployment model – A WAR is packaged together with all of its dependencies. Since the libraries are available in WAR, the container doesn’t have to resolve the WAR’s dependencies.

16. What is the difference between blueprint and spring dependency injection frameworks in JBoss Fuse?

  • Both blueprint and spring are dependency injection frameworks that are used to configure all the dependencies for the applications.
  • Spring is based on Java, and the blueprint is OSGi-specific.
  • Blueprint can install dependencies dynamically at runtime. Spring expects developers to specify the dependencies.

17. What is the difference between bundle and JAR?

  • There is basically no difference. A JAR is a bundle and a bundle is a JAR, the formats are identical. However, a useful bundle requires OSGi metadata in its manifest so that an OSGi framework can manage the visibility of classes between bundles.
  • An OSGi bundle, which can be a JAR or web application archive (WAR) file, contains a bundle manifest file META-INF/MANIFEST. … This header declares the external dependencies of the bundle that the OSGi Framework uses to resolve the bundle. Specific versions or version ranges for each package can be declared. E.g. Manifest File for the camel-osgi Example (below)
Manifest-Version: 1.0
Built-By: cruise
Bundle-Activator: org.apache.camel.osgi.Activator
Created-By: Apache Maven Bundle Plugin
Bundle-License: http://www.apache.org/licenses/LICENSE-2.0.txt
Import-Package: javax.xml.bind,javax.xml.bind.annotation,org.apache.camel
Bnd-LastModified: 1233952200932
Export-Package: org.apache.camel.osgi;version="1.6.0.fuse"
Bundle-Version: 1.5.4.fuse
Bundle-Name: camel-osgi
Bundle-Description: Camel OSGi support
Build-Jdk: 1.5.0_12
Private-Package: !*
Bundle-DocURL: http://open.iona.com
Bundle-ManifestVersion: 2
Bundle-Vendor: IONA Open Source Community
Bundle-SymbolicName: org.apache.camel.camel-osgi
Implementation-Title: Apache Camel
Tool: Bnd-0.0.255
Implementation-Version: 1.5.4.0-fuse

18. Steps to Install Project into Fuse?

  1. Start Fuse using fuse.bat/start.bat. If you start Fuse using start.bat, use client.bat to connect to Fuse.
  2. Execute install command e.g.
JBossFuse:karaf@root> osgi:install -s mvn:com.the.basic.tech.info/apache-camel-cxfrs-webservice/1.0.0-SNAPSHOT
Bundle ID: 296

19. What is CamelContext?

  • Every camel application will have at least one CamelContext. This is the place where we add camel routes. It is similar to ApplicationContext of Spring.
  • Camel context can be thought as a container which keeps all things together. One camel context can have multiple routes inside it.

20. What is a Route in CamelContext?

CamelContext may contain one or more routes. Routes are the integration logic which defines how data will flow in camel context from one endpoint to another.

21. What do you mean by an Endpoint?

Endpoint is end of channel through which system can send or receive messages. This is what we call as destination or source in communication language.

22. What do you mean by Components in Apache Camel?

Components are point of extension in Camel. Components can be an interface to technology, data format, transformers, etc. They may also act as a factory for endpoints.

Apache Components Example

Below is the list of some core components that are provided by Apache Camel.

ComponentArtifactSinceDescription
Beancamel-bean1.0Invoke methods of Java beans stored in Camel registry.
Browsecamel-browse1.3Inspect the messages received on endpoints supporting BrowsableEndpoint.
Classcamel-bean2.4Invoke methods of Java beans specified by class name.
Control Buscamel-controlbus2.11Manage and monitor Camel routes.
Data Formatcamel-dataformat2.12Use a Camel Data Format as a regular Camel Component.
Datasetcamel-dataset1.3Provide data for load and soak testing of your Camel application.
DataSet Testcamel-dataset1.3Extends the mock component by pulling messages from another endpoint on startup to set the expected message bodies.
Directcamel-direct1.0Call another endpoint from the same Camel Context synchronously.
Direct VMcamel-directvm2.10Call another endpoint from any Camel Context in the same JVM synchronously.
Filecamel-file1.0Read and write files.
Kameletcamel-kamelet3.8To call Kamelets
Kamelet Reifycamel-kamelet-reify3.6To call Kamelets (indirectly)
Languagecamel-language2.5Execute scripts in any of the languages supported by Camel.
Logcamel-log1.1Log messages to the underlying logging mechanism.
Mockcamel-mock1.0Test routes and mediation rules using mocks.
Refcamel-ref1.2Route messages to an endpoint looked up dynamically by name in the Camel Registry.
RESTcamel-rest2.14Expose REST services or call external REST services.
REST APIcamel-rest2.16Expose OpenAPI Specification of the REST services defined using Camel REST DSL.
Sagacamel-saga2.21Execute custom actions within a route using the Saga EIP.
Schedulercamel-scheduler2.15Generate messages in specified intervals using java.util.concurrent.ScheduledExecutorService.
SEDAcamel-seda1.1Asynchronously call another endpoint from any Camel Context in the same JVM.
Stubcamel-stub2.10Stub out any physical endpoints while in development or testing.
Timercamel-timer1.0Generate messages in specified intervals using java.util.Timer.
Validatorcamel-validator1.1Validate the payload using XML Schema and JAXP Validation.
VMcamel-vm1.1Call another endpoint in the same CamelContext asynchronously.
XSLTcamel-xslt1.3Transforms XML payload using an XSLT template.
XSLT Saxoncamel-xslt-saxon3.0Transform XML payloads using an XSLT template using Saxon.

Below is the list of some non-core components that are provided by Apache Camel.

ActiveMQcamel-activemq1.0Send messages to (or consume from) Apache ActiveMQ. This component extends the Camel JMS component.
AMQPcamel-amqp1.2Messaging with AMQP protocol using Apache QPid Client.

23. What all EIP patterns have you used and which one of it you used most in your application?

Enterprise Integration Pattern: Camel supports most of the Enterprise Integration Patterns s.t.

  1. Content Based Router
  2. Splitter
  3. Aggregator
  4. Multicast
  5. Recipient List
  6. Log
  7. Message Filter
  8. Re-Sequencer
  9. Wiretap
  10. Bean [bean:beanID[?options]]
  11. Circuit Breaker
  12. Content Enricher
  13. Content Filter
  14. ConvertBodyTo
  15. Correlation Identifier
  16. Dead Letter Channel
  17. From
  18. Hystrix Circuit Breaker (deprecated)
  19. Idempotent Consumer
  20. inOnly
  21. inOut
  22. Marshal and Unmarshal 
  23. Set Body
  24. Set Header
  25. Set Property

24. Difference between SOA & ESB?

  • SOA and ESB are commonly used interchangeably, but they are completely different.
  • SOA is a design pattern which allows application to expose its functionalities as a service over network via communication protocols, whereas ESB is a model which facilitates communication between disparate systems, but ESB can be used as a backbone while implementing SOA.

25. What is Fuse Management Console (HAWTIO)?

  • Fuse also provides complete GUI access to it using FMC (Fuse Management Console). You can find GUI on below URL http://localhost:8181 once JBoss Fuse is running and up.
 Fuse Management Console - Route Diagram
 Fuse Management Console - Route Properties
 Fuse Management Console - Attributes details
 Fuse Management Console - Health Check
  • Everything we did by executing commands can also be done by accessing this browser-based GUI.
  • It becomes extremely helpful when we have more than one container and we are running in a Fabric environment.

26. What is the difference bewteen WireTap and Multicast in Apache Camel?

It is main purpose of WireTap. As example for logging or auditing outside of main thread to do not slow main thread for non-functional operations.

Main Difference is :

  • WireTap is “one-way fork“. Message goes to wire-tapped endpoint in different thread parallel to main and there is no way to get response back from it to main thread. Also it is possible to send to the wire-tapped endpoint other than main body, headers etc. The wireTap component sends the message to just one route while the main flow continues. I don’t think we can achieve concurrency by using wireTap to send a message in parallel to multiple recipients.
  • With Multicast it is possible to “split-then-aggregate” results in main thread after parallel or sequential processing. Also it is not limited how many endpoints will be multicasted, while WireTap can have only one endpoint to send to. The Multicast router sends the message through multiple routes and waits for all of them to continue before the main flow can continue with the next message processor.

27. What is the difference between Multicast and RecipientList EIP?

  • Multicast allows a hard coded recipient list and recipientList(..) allows endpoints computed at runtime dynamically. 
  • The Multicast pattern, is a variation of the recipientList pattern with a fixed destination pattern.

28. What is the difference between direct:, seda:, direct-vm: and vm: in Apache Camel?

  • direct: – single CamelContext, synchronous (blocks producer)
  • seda: – single CamelContext, asynchronous (does not block producer)
  • direct-vm: – multiple CamelContext, synchronous (blocks producer)
  • vm: – multiple CamelContext, asynchronous (does not block producer)

In relation to “what to use when” :

  • Use direct: for calling normally between endpoints in a camel context
  • Use seda: when you need parallelisation or queues, but dont want to use jms:
  • Use vm: when calling between applications.

29. What exactly is Digital Transformation according to you?

Digital transmission is a procedure of sharing information digitally.

30. How we can deploy a normal jar in JBoss Fuse?

First of all we need to create a bundle using Maven, just in the same way that we might create a JAR file. To do this, we need to add the Maven Bundle Plugin to our Maven POM, and set your packaging type to bundle. An OSGi bundle is just a certain type of Java application. It looks pretty much like a .jar file, but it also has some metadata inside, which describes the application’s dependencies and configuration.

Once we have created a bundle, and we want to deploy it into JBoss Fuse – known as installing a bundle – we should use the following command from the Fuse console:

osgi:install <mvn: artifact>

The mvn: prefix means that JBoss Fuse will use Maven to look for the bundle. It look for bundle in the local Maven repository, and it also searches a number of public repositories, such as Maven Central.

31. What is feature.xml? How we can create a custom feature repository?

  • Red Hat JBoss Fuse provides a scalable unit of deployment, the feature, which enables you to deploy multiple bundles (and, optionally, dependencies on other features) in a single step.
  • Alternatively, you could switch to using the FAB model of deployment, which automatically aggregates related bundles at deployment time, without requiring any additional configuration.
  • For creating a custom feature repository, choose a convenient location for the feature repository on your file system—for example, C:\Projects\features.xml—and use your favorite text editor to add the following lines to it:
<?xml version="1.0" encoding="UTF-8"?>
 <features name="CustomRepository">
</features>

Now, we can add a feature to the custom feature repository like as below:

<?xml version="1.0" encoding="UTF-8"?>
<features name="CustomRepository">
  <feature name="example-camel-bundle">    
    <feature>camel-core</feature>
    <feature>camel-spring-osgi</feature>
    <feature>servicemix-camel</feature>
    <bundle>file:C:/Projects/camel-bundle/target/camel-bundle-1.0-SNAPSHOT.jar</bundle>
  </feature>
</features>

To check whether the features service successfully parses the new feature entry, enter the following pair of console commands:

karaf@root> features:addUrl file:C:/Projects/features.xml
karaf@root> features:refreshUrl
karaf@root> features:list
...
[uninstalled] [0.0.0                 ] example-camel-bundle                 CustomRepository
...

32. How we can deploy an OSGi configuration automatically in JBoss Fuse using feature repository?

By adding a configfile element to a feature, you can ensure that an OSGi configuration file gets added to the InstallDir/etc directory at the same time that the feature is installed. This means that you can conveniently install a feature and its associated configuration at the same time.For example, given that the org.fusesource.fuseesb.example.cfg configuration file is archived in a Maven repository at mvn:org.fusesource.fuseesb.example/configadmin/1.0/cfg, you could deploy the configuration file by adding the following element to the feature:

<configfile finalname="etc/org.fusesource.fuseesb.example.cfg">
  mvn:org.fusesource.fuseesb.example/configadmin/1.0/cfg
</configfile>

33. Can we consider Microservices equals to OSGi?

  • Good question! I don’t see OSGi and microservices being equal. OSGi is a way of modularising Java apps, but each OSGi bundle still has shared dependencies – e.g. Camel, CXF, transaction manager, etc. – and these are provided by the container (JBoss Fuse).
  • Contrast that with microservices deployed in Docker containers on Kubernetes, where each microservice is self-contained and autonomous. All of the microservice’s dependencies are inside the Docker container. Containers are disposable but traditional application servers? Not so much.
  • OSGi containers like Fuse are designed to run many different modules (bundles) in a single container. This is different from a microservice approach, where each service is independent and runs in its own process.

34. Where and how do we can configure the logging in JBoss Fuse?

Red Hat JBoss Fuse uses the OPS4j Pax Logging system. Pax Logging is an open source OSGi logging service that extends the standard OSGi logging service to make it more appropriate for use in enterprise applications. It uses Apache Log4j as the back-end logging service. Pax Logging has its own API, but it also supports the following APIs:

  • Apache Log4j
  • Apache Commons Logging
  • SLF4J
  • Java Util Logging

Fuse Logging system configuration steps

  • etc/system.properties—the configuration file that sets the logging level during the container’s boot process. The file contains a single property, org.ops4j.pax.logging.DefaultServiceLog.level, that is set to ERROR by default.
  • org.ops4j.pax.logging—the PID used to configure the logging back end service. It sets the logging levels for all of the defined loggers and defines the appenders used to generate log output. It uses standard Log4j configuration. By default, it sets the root logger’s level to INFO and defines two appenders: one for the console and one for the log file. Note: The console’s appender is disabled by default. To enable it, add log4j.appender.stdout.append=true to the configuration.
JBossFuse:karaf@root> config:edit org.ops4j.pax.logging
JBossFuse:karaf@root> config:propappend log4j.appender.stdout.append true
JBossFuse:karaf@root> config:update

Changing the log levels

The most useful logger to change when trying to debug an issue with Red Hat JBoss Fuse is the root logger. Suppose You want to set the logging level to generate more fine grained messages. To do so you change the value of the org.ops4j.pax.logging PID’s log4j.rootLogger property so that the logging level is one of the following:

  • TRACE
  • DEBUG
  • INFO
  • WARN
  • ERROR
  • FATAL
  • OFF
JBossFuse:karaf@root> config:edit org.ops4j.pax.logging
JBossFuse:karaf@root> config:propset log4j.rootLogger "DEBUG, out, osgi:VmLogAppender"
JBossFuse:karaf@root> config:update

35. What are the commands for managing logging output in JBoss Fuse?

The Red Hat JBoss Fuse console provides the following commands for managing logging output:

log:display

Displays the most recent log entries. By default, the number of entries returned and the pattern of the output depends on the size and pattern properties in the org.apache.karaf.log.cfg file. You can override these using the -p and -d arguments.

log:display-exception

Displays the most recently logged exception.

log:get

Displays the current log level.

log:set

Sets the log level.

log:tail

Continuously display log entries.

log:clear

Clear log entries.

36. What is the latest version of the JBoss Fuse and its components?

Red Hat Fuse component details for each product release are listed below. As part of the release process, multiple open-source community components may be added or removed for dependency or compatibility purposes; other components may be included as technology previews.

Red Hat Fuse 7.10

The following community components have been integrated into Red Hat Fuse 7.10.

ComponentVersion
Spring Boot2.3.12.RELEASE
Apache Karaf4.2.12
Karaf Maven Plugin4.2.12
Apache Camel2.23.2
Wildfly Camel5.8.0
Apache CXF (on Apache Karaf and Spring Boot)3.3.6
Apache CXF (on JBoss EAP)3.3.12
Hawtio2.0.0
Hibernate core5.3.23
OpenShift Maven Plugin1.3.0
Narayana5.11.3
Undertow2.2.12
RH SSO7.4.9

Red Hat Fuse 7.9

The following community components have been integrated into Red Hat Fuse 7.9.

ComponentVersion
Spring Boot2.3.9.RELEASE
Apache Karaf4.2.11
Karaf Maven Plugin4.2.11
Apache Camel2.23.2
Wildfly Camel5.7.0
Apache CXF (on Apache Karaf and Spring Boot)3.3.6
Apache CXF (on JBoss EAP)3.3.9
Hawtio2.0.0
Hibernate core5.3.20
Fabric8 Maven Plugin4.3.0
Narayana5.11.3
Undertow2.2.5
RH SSO7.4.6

Red Hat Fuse 7.8

The following community components have been integrated into Red Hat Fuse 7.8.

ComponentVersion
Spring Boot2.3.4.RELEASE
Apache Karaf4.2.9
Karaf Maven Plugin4.2.9
Apache Camel2.23.2
Wildfly Camel5.6.0
Apache CXF (on Apache Karaf and Spring Boot)3.3.6
Apache CXF (on JBoss EAP)3.3.5
Hawtio2.0.0
Hibernate core5.3.17
Fabric83.0.11
Fabric8 Maven Plugin3.5.42
Narayana5.9.8
Undertow2.0.30
RH SSO7.4.2

Red Hat Fuse 7.7

The following community components have been integrated into Red Hat Fuse 7.7.

ComponentVersion
Spring Boot1.5.22.RELEASE

2.1.6.RELEASE
Apache Karaf4.2.6
Karaf Maven Plugin4.2.6
Apache Camel (on Apache Karaf, JBoss EAP and Spring Boot 1.5)2.21.0
Apache Camel (on Spring Boot 2.1.3)2.23.2
Wildfly Camel5.5.0
Apache CXF (on Apache Karaf and Spring Boot)3.2.7
Apache CXF (on JBoss EAP)3.2.11
Hawtio2.0.0
Hibernate core5.3.15
Fabric83.0.11
Fabric8 Maven Plugin (in Karaf and Spring Boot 1)3.5.33
Fabric8 Maven Plugin (in Spring Boot 2)3.5.42
Narayana (on Apache Karaf and Spring Boot)5.9.8
Narayana (on JBoss EAP)5.9.6
Undertow (on Apache Karaf and Spring Boot)2.0.30
Undertow (on JBoss EAP)2.0.28
RH SSO7.3.7

Red Hat Fuse 7.6

The following community components have been integrated into Red Hat Fuse 7.6.

ComponentVersion
Spring Boot1.5.22.RELEASE

2.1.6.RELEASE
Apache Karaf4.2.6
Karaf Maven Plugin4.2.6
Apache Camel (on Apache Karaf, JBoss EAP and Spring Boot 1.5)2.21.0
Apache Camel (on Spring Boot 2.1.3)2.23.2
Wildfly Camel5.4.0
Apache CXF (on Apache Karaf and Spring Boot)3.2.7
Apache CXF (on JBoss EAP 7.2.5)3.2.5
Hawtio2.0.0
Hibernate5.3.13
Fabric83.0.11
Fabric8 Maven Plugin (in Karaf and Spring Boot 1)3.5.33
Fabric8 Maven Plugin (in Spring Boot 2)3.5.42
Narayana5.9.6
Undertow2.0.26
RH SSO7.3.5

Red Hat Fuse 7.5

The following community components have been integrated into Red Hat Fuse 7.5.

ComponentVersion
Spring Boot1.5.19.RELEASE

2.1.6.RELEASE
Apache Karaf4.2.6
Karaf Maven Plugin4.2.6
Apache Camel (on Apache Karaf, JBoss EAP and Spring Boot 1.5)2.21.0
Apache Camel (on Spring Boot 2.1.3)2.23.2
Wildfly Camel5.3.0
Apache CXF (on Apache Karaf and Spring Boot)3.2.7
Apache CXF (on JBoss EAP 7.2.3)3.2.5
Hawtio2.0.0
Hibernate5.3.10
Fabric83.0.11
Fabric8 Maven Plugin3.5.33
Narayana5.9.3
Undertow2.0.22
RH SSO7.3.3

Red Hat Fuse 7.4

The following community components have been integrated into Red Hat Fuse 7.4.

ComponentVersion
Spring Boot1.5.19.RELEASE

2.1.3.RELEASE
Apache Karaf4.2.0
Karaf Maven Plugin4.2.0
Apache Camel (on Apache Karaf, JBoss EAP and Spring Boot 1.5)2.21.0
Apache Camel (on Spring Boot 2.1.3)2.23.0
Wildfly Camel5.3.0
Apache CXF (on Apache Karaf and Spring Boot)3.2.7
Apache CXF (on JBoss EAP 7.2.1)3.2.7
Hawtio2.0.0
Hibernate5.3.10
Fabric83.0.11
Fabric8 Maven Plugin3.5.33
Narayana5.9.1
Undertow2.0.20

Red Hat Fuse 7.3

The following community components have been integrated into Red Hat Fuse 7.3.

ComponentVersion
Spring Boot1.5.17.RELEASE
Apache Karaf4.2.0
Karaf Maven Plugin4.2.0
Apache Camel2.21.0
Wildfly Camel5.3.0
Apache CXF (on Apache Karaf and Spring Boot)3.2.7
Apache CXF (on JBoss EAP)3.2.5
Hawtio2.0.0
Hibernate5.3.7
Fabric83.0.11
Fabric8 Maven Plugin3.5.33
Narayana5.9.0
Undertow2.0.15

Red Hat Fuse 7.2

The following community components have been integrated into Red Hat Fuse 7.2.

ComponentVersion
Spring Boot1.5.16.RELEASE
Apache Karaf4.2.0
Karaf Maven Plugin4.2.0
Apache Camel2.21.0
Wildfly Camel5.2.0
Apache CXF3.1.11
Hawtio2.0.0
Hibernate5.1.16
Fabric83.0.11
Fabric8 Maven Plugin3.5.33
Narayana5.5.31
Undertow1.4.18

Red Hat Fuse 7.1

The following community components have been integrated into Red Hat Fuse 7.1.

ComponentVersion
Spring Boot1.5.13.RELEASE
Apache Karaf4.2.0
Karaf Maven Plugin4.2.0
Apache Camel2.21.0
Wildfly Camel5.2.0
Apache CXF3.1.11
Hawtio2.0.0
Hibernate5.1.13
Fabric83.0.11
Fabric8 Maven Plugin3.5.33
Narayana5.5.31

Red Hat Fuse 7.0

The following community components have been integrated into Red Hat Fuse 7.0.

ComponentVersion
Spring Boot1.5.12.RELEASE
Apache Karaf4.2.0
Karaf Maven Plugin4.2.0
Apache Camel2.21.0
Wildfly Camel5.1.0
Apache CXF3.1.11
Hawtio2.0.0
Hibernate5.1.10
Fabric83.0.11
Fabric8 Maven Plugin3.5.33
Narayana5.5.31

JBoss Fuse 6.3

The following community components have been integrated into JBoss Fuse 6.3.

ComponentVersion
Apache ActiveMQ5.11.0
Apache Camel2.17.0
Apache CXF3.1.5
Apache Karaf2.4
Fabric81.2
SwitchYard2.1.0
Hibernate4.2.22

Fuse Integration Services 2.0

The following community components have been integrated into Fuse Integration Services 2.0 for OpenShift.

ComponentVersion
Spring Boot1.4.1.RELEASE
Apache Camel2.18.1 (Java image)

2.17.0 (Karaf image)
Apache CXF3.1.5
Apache Karaf2.4
Karaf Maven Plugin4.0.8
Fabric82.2.170
Fabric8 Maven Plugin3.1.80

JBoss Fuse 6.2.1

The following community components have been integrated into JBoss Fuse 6.2.1.

ComponentVersion
Apache ActiveMQ5.11.0
Apache Camel2.15.1
Apache CXF3.0.4
Apache Karaf2.4
Fuse Fabric7.2.0 (Fabric8 1.2)
SwitchYard2.0.1

JBoss Fuse 6.2

The following community components have been integrated into JBoss Fuse 6.2.

ComponentVersion
Apache ActiveMQ5.11.0
Apache Camel2.15.1
Apache CXF3.0.4
Apache Karaf2.4
Fuse Fabric7.2.0 (Fabric8 1.2)
SwitchYard2.0.1

JBoss Fuse 6.1

The following community components have been integrated into JBoss Fuse 6.1.

ComponentVersion
Apache ActiveMQ5.9.0
Apache Camel2.12.0
Apache CXF2.7.0
Apache Karaf2.3
Fuse Fabric7.2.0 (Fabric8 1.2)

JBoss Fuse 6.0

The following community components have been integrated into JBoss Fuse 6.0.

ComponentVersion
Apache ActiveMQ5.8.0
Apache Camel2.10.0
Apache CXF2.6.0
Apache Karaf2.3
Fuse Fabric7.2.0

37. What does camel provides to integrate with Database and which component is the best?

We can use jdbc component or sql component to integrate with Database. In our application the SQL component with databases being used.

camel-jdbc Component

We need to add the following dependency to their pom.xml for this component:

<dependency>
    <groupId>org.apache.camel</groupId>
    <artifactId>camel-jdbc</artifactId>
    <version>x.x.x</version>
    <!-- use the same version as your Camel core version -->
</dependency>

Note: This component can only be used to define producer endpoints, which means that you cannot use the JDBC component in a from() statement. E.g. First we need to register our datasource in the Camel registry as testdb: then we can use it in our camel route as below. In this component we have to pass the query in camel body.

from("timer://MoveNewCustomersEveryHour?period=3600000")
    .setBody(constant("select * from customer where create_time > (sysdate-1/24)"))
    .to("jdbc:testdb")
    .split(body())
        .process(new MyCustomerProcessor()) //filter/transform results as needed
        .setBody(simple("insert into processed_customer values('${body[ID]}','${body[NAME]}')"))
        .to("jdbc:testdb");

camel-sql Component

We can use camel-sql Component in our application in Camel route as below. First we need to add maven artifact in pom.xml.

<dependency>
    <groupId>org.apache.camel</groupId>
    <artifactId>camel-sql</artifactId>
    <version>x.x.x</version>
    <!-- use the same version as your Camel core version -->
</dependency>
from("direct:query")
    .to("sql:select * from projects where project in (:#in:names) order by id")
    .to("log:query")
    .to("mock:query");

38. What is basic difference between camel-jdbc and camel-sql components and which one is advance?

  • In case of SQL component the query is a property of the endpoint and it uses message payload as parameters passed to the query. Hence, it is much easier to use parameterized queries.
  • In case of JDBC component we have to pass the query in camel body. Also the SQL component uses spring-jdbc behind the scenes for the actual SQL handling, while JDBC component uses the standard JDBC API. 
  • So, Camel SQL component is much advanced as we can also make use of features like Spring transaction.

39. How we can split InputStream/File by length not by token?

Under Splitter EIP “Splitting big messages”, it briefly discusses using streaming with the splitter in context of the tokenizer, which only processes strings. It states that tokenizer uses java.util.Scanner to read chunks of data into memory. So the Scanner reads a “stream” of data, based on a token. The Scanner object is then passed back to Camel as an Expression, which Camel then uses to iterate over and deliver as parts.  Is this correct? Hence we have to handle this in Customized Iterator I mean we have to split big binary file into smaller chunks in MyCustomFileChunkIterator() processor e.g.

 public void configure() throws Exception{
        from( "file://file-item-list/general?initialDelay=1000&delay=5000&delete=true" )
            .transacted( "PROPAGATION_REQUIRED" )
            .split(ExpressionBuilder.beanExpression(new MyCustomFileChunkIterator(),  "iterator"))  // split big file of items into smaller chunks
            .streaming()
            .to("activemq:queue:file-item-sublist-request");
    }

40. How we can implement Concurrency/Parallel Processing in Apache Camel?

Apache Camel offers various components and enterprise integration patterns (EIPs) to achieve concurrency.

1. Custom thread pool

When using Multicast EIP for parallel processing, Camel uses a default thread pool which has a maximum pool size of 20, limiting the number of parallel threads that can be spanned to 20:

<threadPoolProfile id=”defaultThreadPoolProfile” defaultProfile=”true” poolSize=”10” maxPoolSize=”20” maxQueueSize=”1000” allowCoreThreadTimeOut=”false” rejectedPolicy=”CallerRuns”/>

With these pool size settings, multicast invocation becomes a major performance bottleneck when processing higher transactions per second (TPS).

It’s recommended to use a custom thread pool tuned for the performance needs of each use case rather than using default thread pool settings as below.

<threadPool id=”customThreadPool” threadName=”customThread” poolSize=”300” maxPoolSize=”300”/>
from (“mainRoute”)
.multicast()
.aggregationStrategy (new ResponseAggregator())
.parallelProcessing()
.executorServiceRef(customThreadPool)
.to (“subRoute1”, “subRoute2”, "subroute3”)

2. Streaming

Note: Streaming should be applied only if the AggregationStrategy does not depend on the order of responses from the sub-routes. An example is:

from (“mainRoute”)
.multicast()
.aggregationStrategy (new ResponseAggregator())
.parallelProcessing()
.streaming()
.executorService(executorService)
.to (“subRoute1”, “subRoute2”, "subroute3”)

3. Parallel aggregation

Note: Enabling parallel aggregation would require the AggregationStrategy to be implemented as thread safe. An example is:

from (“mainRoute”)
.multicast()
.aggregationStrategy(new ResponseAggregator()
.parallelAggregate()
.parallelProcessing()
.streamlining()
.executorService (executorService)
.to (“subRoute1, “subRoute2”, "subroute3”)

41. What are the Error Handlers provided by Apache Camel?

Error HandlerDescription
DefaultErrorHandlerThis is the default error handler that’s automatically enabled, in case no other has been configured.
DeadLetterChannelThis error handler implements the Dead Letter Channel EIP.
TransactionErrorHandlerThis is a transaction-aware error handler extending the default error handler.
NoErrorHandlerThis handler is used to disable error handling altogether.
LoggingErrorHandlerThis error handler just logs the exception. This error handler is deprecated, in favor of using the DeadLetterChannel error handler, using a log endpoint as the destination.

42. How we can retry processing a message from a certain point back or an entire route in Apache Camel?

By default Apache Camel will perform any redelivery (retry) attempts from the point of failure. So if we want to retry from a point before this, we would need to split up our route for implementing redeliveryPolicy.

<!-- this is the processor that will fail the first 2 attempts -->
<bean id="myProcessor" class="org.apache.camel.processor.RedeliverToSubRouteTest.MyProcessor"/>

<camelContext xmlns="http://camel.apache.org/schema/spring">

    <!-- setup no error handler with an id, we refer to from the 2nd route -->
    <errorHandler id="noErrorHandler" type="NoErrorHandler"/>

    <!-- configure on exception to redelivery at most 2 times when an IOException was thrown
         do not use redelivery delay to run unit test faster -->
    <onException>
        <exception>java.io.IOException</exception>
        <redeliveryPolicy maximumRedeliveries="2" redeliveryDelay="0"/>
    </onException>

    <!-- 1st route, no need to setup error handler, as it will use the default error handler -->
    <route>
        <from uri="direct:start"/>
        <to uri="mock:a"/>
        <to uri="direct:sub"/>
        <to uri="mock:c"/>
    </route>

    <!-- disable error handler on this route, so the entire route can be redelivered when called from the 1st route -->
    <route errorHandlerRef="noErrorHandler">
        <from uri="direct:sub"/>
        <to uri="mock:b"/>
        <process ref="myProcessor"/>
    </route>
</camelContext>

Adding a custom Processor (MyProcessor.java) for throwing exception for the testing.

package org.apache.camel.processor.RedeliverToSubRouteTest

public static class MyProcessor implements Processor {

    private int counter;

    @Override
    public void process(Exchange exchange) throws Exception {
        // use a processor to simulate error in the first 2 calls
        if (counter++ < 2) {
            throw new IOException("Exception Occured. Retry !!!");
        }
        exchange.getIn().setBody("No Exception - Relax.");
    }
}

43. How we can DEBUG a Camel Route?

  • Tracer to trace in commons-logging / log4j each step that Camel takes. E.g.
<camelContext trace="true" xmlns="http://activemq.apache.org/camel/schema/spring">
...
</camelContext>
  • Debugger to let you set breakpoints at points in the route and examine historic message exchanges. E.g. camel-test-junit5
Debugger Apache Camel
  • Debug from your unit test if you use the Camel camel-test component.

Some third party tools offer Apache Camel route debugging.

Thank you for reading. Will be adding more Q&A, keep visiting 🙂