Integrating Apache ActiveMQ with JBoss

Integration with application servers is a common scenario in the enterprise Java world, especially when it comes to messaging. ActiveMQ is a JMS 1.1 compliant, open source, Apache Licensed, message oriented middleware (MOM) with many, many features far beyond the JMS specification. ActiveMQ offers many different points of connectivity, many cross language clients and many pluggable transport protocols including integration with any J2EE 1.4 application server.

One of the application servers in the open source world is JBoss. A very common requirement is to configure ActiveMQ as the messaging infrastructure within JBoss. Although there is a bit of documentation on this integration, this article seeks to provide much more detail and explanation. So if you have a need to integrate ActiveMQ with JBoss, this article is for you.

This article explains how to configure JBoss to start up ActiveMQ as part of its lifecycle and how to configure the ActiveMQ resource adapter to handle the messaging and transactionality between ActiveMQ and JBoss.


Below are the software requirements for this article with links to download each:

Though this article is using Unix, the installation and integration will work on any platform running Sun Java. It is recommended that each piece of software be downloaded before working through the steps is this article. Once each piece of software has been downloaded, proceed to the first step.

Install the J2SE 1.5

The first step in this process is to install Java 1.5 and verify that it runs correctly. Using the link above, find, download and install the correct version of Java for your platform. Once Java is installed and in the PATH, test it to see that it runs correctly using the following command:

Depending upon your platform and the exact build number of Java 1.5, your output may vary slightly. As long as it's Java 1.5 and the version information is output, you should be ready to proceed to the next step.

Install Apache Ant

The second step is to install Apache Ant. Simply download it using the link above, expand somewhere on your hard drive and place the bin directory in the PATH. This will allow you to test it quickly using the commands below:

As long as you see the version output above, Ant should be usable. If you did not see the version output or received an error, consult the Ant documentation or mailing list archives to work out the issue. Please note that Ant is not used until the end of this whole exercise to test the integration.

Install the JBoss Application Server

The third step in this process is to install JBoss and make sure it runs correctly before installing and configuring ActiveMQ. Upon downloading JBoss-4.0.4, expand it in a place where it can create a directory. Next, run the server using the following commands:

The first few lines of output from the JBoss startup indicates the configuration being used but the last line is the most important one. It tells you that JBoss has been started successfully on your system. For an extra measure of assurance, visit http://localhost:8080/web-console/ in a web browser to make sure you are able to see the JBoss web console. If you can see this console, everything should be ready to go.

As a side note, the left-hand side of the web-console requires that the Java plugin be properly installed. This is supposed to take place when installing the J2SE, so if it did not work correctly for you, I suggest that you consult some documentation about any errors you may be seeing. The Java plugin is not required for JBoss or ActiveMQ to function properly, it is simply for the JBoss web-console.

Once JBoss is installed properly, shut it down using either the shutdown script or by simply typing ctrl-c to activate the shutdown hook. Once it is shut down, proceed to the next step.

Prepare for Integrating Apache ActiveMQ with the JBoss Application Server

The fourth step is to prepare your environment for integrating ActiveMQ with JBoss. If you haven't done so already, download Apache ActiveMQ using the link above. As of the writing of this article, the latest released version is 4.0.2-RC4. Upon downloading this archive, expand it in a place where it can create a directory, preferably in the same location where JBoss was expanded. Verify that the ActiveMQ RAR file is included using the following commands:

This is simply a table of contents of the RAR file. There should only be one reason that this will fail - an incomplete download of the ActiveMQ tarball or zip file. Beyond that, depending on the version you download, some of the library versions may be slightly different.

Now go back to the JBoss installation and create a directory for ActiveMQ in the JBoss deploy directory for the default JBoss context. Below are the commands to achieve this task:

NOTE: The creation of a directory is not required but is the easiest way to set up the ActiveMQ RAR when you're just getting started. This is due to the flexibility it affords during the development phase for the configuration to be changed very easily. The alternative is to JAR up the directory as a RAR file once the configuration is solid enough that it no longer needs to be changed. But leaving everything in a directory during development is the easiest path.

Now expand the activemq-ra-4.0.2.rar into the current working directory:

Below is a quick listing of the contents of that directory:

Now it's time to configure ActiveMQ.

Configuring Apache ActiveMQ

The fifth step is to actually configure ActiveMQ for integration with JBoss. Remember that you should be sitting in the following directory:

You may or may not have installed JBoss in /opt, that doesn't particularly matter. What does matter is that you're sitting in the directory that was created above to hold the contents of the expanded ActiveMQ RAR file.

NOTE: A RAR file is a Resource adapter ARchive (RAR). Resource adapters are a concept from the J2EE Connector Architecture (JCA) and are used to interface with Enterprise Information Systems (EIS), i.e., systems external to the application server (e.g., relational databases, mainframes, MOMs, accounting systems, etc.). Resource adapters are often referred to as J2EE connectors and are very similar to the concept of a device driver for, say, a printer in that they contain information specific to connecting to a particular system. The difference with JCA is that that connection has been formalized in specification for Java. So the overall concepts of JCA is for connection to any EIS, but what does that mean? JCA 1.5 provides connectivity and more via the following contracts:

Version 1.0 Contracts

In version 1.0 of the Connector Architecture, three contracts are defined to address the functions mentioned above:

  • Connection Management Contract: Lets applications connect to an EIS through the resource adapter. It also allows the application server to pool connection requests to the EIS.
  • Transaction Management Contract: Allows an application to manage and perform transactional access across one-to-many EIS resource managers.
  • Security Contract: Provides support for secure access to the EIS.

New Contracts in Version 1.5

In version 1.5 of the J2EE Connector Architecture, there are more contracts that a resource adapter must support, as new functionality and features made their way into the specification. A resource adapter can support these four new contracts by implementing the required interfaces defined in the specification for each contract.

  • Lifecycle Management Contract: Lets the application server manage the lifecycle – that is, the startup and shutdown functionality – of the resource adapter.
  • Work Management Contract: Allows the resource adapter to do work by submitting it to an application server for execution. Since the application server does the work for the resource adapter, the resource adapter needn't worry about thread management. Instead, the application server manages this aspect efficiently and can use thread pooling if necessary. Although the work management contract is not required (the resource adapter can choose to manage its own thread for work), it is definitely recommended.
  • Transaction Inflow Contract: Allows a resource adapter to propagate an imported transaction to an application server, as well as flow-in transaction completion and crash recovery initiated by an EIS.
  • Message Inflow Contract: Allows the resource adapter to synchronously or asynchronously deliver messages to endpoints in the application server, irrespective of message style, semantics, and infrastructure.

Quoted from What's New in the J2EE Connector Architecture 1.5

For more information about JCA, please consult the J2EE Connector Architecture documentation.

Open the META-INF/ra.xml file and look for the following section:


The section above is used to tell the ActiveMQ RAR where ActiveMQ is located. By default, the in-VM protocol is commented out in favor of the tcp protocol. This will find ActiveMQ running on any interface on the localhost on port 61616. It's ok to just leave this alone if you don't mind the inefficiency of communicating within the JVM via TCP. However, it is recommended that vm:// transport be used for an embedded broker, so comment out the tcp:// transport and uncomment the vm:// transport. Below is an example of this:


Because we're embedding ActiveMQ inside of JBoss, it is more efficient to use the vm:// transport, rather than to perform messaging over the tcp:// transport.

Now look further down the META-INF/ra.xml file and locate the following section:


The section above needs to be changed to uncomment the second to last line and remove/replace the empty element that is above it. Below is an example of how this should be changed:


This change tells the ActiveMQ RAR to read a configuration file named broker-config.xml (the xbean: that proceeds the filename is simply a hint to class doing the reading of the configuration file) which is located on the CLASSPATH. In this case, the broker-config.xml file is located in the activemq-ra.rar directory. Save the changes to that file and then open the broker-config.xml file.

The broker-config.xml file is the ActiveMQ configuration file. This is the file used to configure ActiveMQ. The default contents of this file are usable, but should be customized to suit your environment. There are several items of note about this configuration. The most prominent sections to note in this file are the <persistenceAdapter> element and the <transportConnectors> and <networkConnectors> elements as seen below:


The first change to this file is to add the brokerName attribute to the broker element and provide a name:

In addition, this same name is used further down the configuration to provide a name for the <transportConnector> element:

Now we'll tell ActiveMQ not to initialize JMX because we'll use the existing one that JBoss has:

The <persistenceAdapter> element should be reconfigured to store its data in an appropriate place. On JBoss, that's most likely within the "data" directory of the server configuration you're using. We're going to set this dynamically using an XBean and Spring feature that allows us to inject system properties values into the configuration. First this needs to be enabled:

Now, modify the dataDirectory attribute of the journaledJDBC element to be the following: ${}/activemq.

The <transportConnectors> element is used to advertise the ActiveMQ broker for client-to-broker communications and the <networkConnectors> element advertises the ActiveMQ broker for broker-to-broker communications. The default configuration is to use the ActiveMQ multicast transport for both. This is simply an easy configuration under which to get ActiveMQ up and running, so we'll just leave it at that for the time being.

NOTE: There are far more configuration options available for ActiveMQ than are noted here. The configuration above is only enough to just get ActiveMQ up and running, nothing more. For more information on the ActiveMQ configuration, see the ActiveMQ 4.1 XML Reference.

Now we just need to start up JBoss to assure that it comes up correctly without error using the same commands we used previously to start JBoss:

As long as JBoss comes up without error, you're ready to move on to the next step.

Configuring JBoss

The sixth step is to configure JBoss to initialize and start ActiveMQ whenever JBoss starts up. This is accomplished using an XML file that abides by the JBoss JCA DTD for data sources. Like most other Java application servers on the market, the JBoss architecture uses the J2EE Connector Architecture to manage connections of any kind including JDBC, JMS, etc. and the JBoss JCA DTD denotes the allowed contents for creating an XML data source instance to configure JBoss JCA. Below is an example XML data source instance for use with JBoss:


This XML instance configures a JMS QueueConnectionFactory and a JMS TopicConnectionFactory and makes them available via JNDI. Also defined in this file are some {{AdminObject}}s which are used to specify a topic and a queue. This file should be dropped into the JBoss deploy directory. Its name (*-ds.xml) will cause it to be picked up by the JBoss deployer upon startup. Speaking of which, once this file is in place, a quick smoke test can be performed by simply starting up the JBoss server. Below is an example of the output that should be seen:

Note the startup messages from both ActiveMQ and from the AdminObject}}s creating an {{ActiveMQQueue and an ActiveMQTopic. These are good indications that the configuration is correct, but needs to be verified a bit further. This is covered in the next section.

Testing the Integration

The seventh and final step is to perform a slightly more comprehensive smoke test of the integration. This can be accomplished using Apache Ant via the examples that come with the ActiveMQ binary distribution. An Ant build.xml file is included which provides easy access to a simple consumer and a simple producer. The producer will be used to send messages that are received by the consumer. To proceed with this testing, just follow the steps below:

  1. In the first terminal, start up JBoss. The same startup script can be used here as was used above.
  2. In the second terminal, use the commands below to run the ActiveMQ consumer:
  3. In the third terminal, use the commands below to run the ActiveMQ producer:

Step 1 above just starts up JBoss. Step 2 above starts up a simple message consumer that comes with ActiveMQ. Step 3 above starts up a simple message producer that comes with ActiveMQ. Though the message consumer and message producer are simple utilities, the each one accepts many parameters making them extremely useful for testing ActiveMQ configurations.

To paraphrase, what just happened was that the message producer sent 10 messages to the TEST.FOO destination and the message consumer received 10 messages from the TEST.FOO destination. Despite being a simple test, it does utilize the ActiveMQ broker, albeit only on a single machine. The next logical step is to set up a full network of ActiveMQ brokers.

After setting up one broker within one instance of JBoss, setting up another is made much easier, but requires another machine or operating system instance. But that's a whole separate article and something to address another day.


What has been demonstrated here is the integration of ActiveMQ with the JBoss application server. This integration is quite common and performed by many enterprises. I hope that this was helpful to people interested in the integration of ActiveMQ with JBoss application server. If you have any questions or are interested in consulting services surrounding ActiveMQ, please contact us for more information.


Below are the configurations for use with both Spring 1.x and Spring 2.x:

© 2004-2011 The Apache Software Foundation.
Apache ActiveMQ, ActiveMQ, Apache, the Apache feather logo, and the Apache ActiveMQ project logo are trademarks of The Apache Software Foundation. All other marks mentioned may be trademarks or registered trademarks of their respective owners.
Graphic Design By Hiram