Embedded ActiveMQ Broker with Mule

By | June 26, 2014

In this post I will show how an embedded ActiveMQ broker is automatically started when using the broker URL “vm://localhost” in a Mule JMS connector, without any additional configuration, and how to disable this behaviour. I will also look at how to explicitly configure an embedded ActiveMQ broker in a Mule configuration file.

As documented in the Mule documentation under ActiveMQ Integration, Mule will automatically start an embedded instance of ActiveMQ if an ActiveMQ JMS connector is defined with a broker URL equal to “vm://localhost”. The same holds if a regular JMS connector is created with a reference to an ActiveMQ connection factory with the URL above.
This behaviour can be verified using the following steps:

  • Create a Mule project in an IDE with the Mule Studio plug-in installed.
  • Add the ActiveMQ-all JAR-file to the library path of the new project.
  • In src/main/resources of the new project, create a file named “log4j.xml” with the following contents:
  • Paste the following into the Mule configuration file of the new project:
  • Right-click the Mule configuration file and select Run As -> Mule Application.
  • Stop the Mule application.

Looking at the log output in the console, the following can be observed:

As can be seen in lines 13 and 14, an instance of ActiveMQ is started. This behaviour is implemented in the ActiveMQ class org.apache.activemq.transport.vm.VMTransportFactory and is thus not something Mule controls.
In some cases it can be desirable not to automatically start an embedded ActiveMQ, for instance if this is taken care of by another part of the application. This can be accomplished by adding the “create=false” parameter to the broker URL.
The modified Mule configuration file looks like this:

If we now run the Mule application again, the result will be an exception saying that there is no broker named “localhost”:

In order to fix this error and assuming that more control over the embedded ActiveMQ instance is desired, the Mule configuration file is again modified to include an embedded ActiveMQ broker. The result looks like this:

Since the <amq:broker> element is used to define the embedded ActiveMQ broker, we also need to add the xbean-spring library to the classpath of the project. An appropriate version of this library can be downloaded using this link.
For additional information on how to configure ActiveMQ using XML configuration, please refer to the ActiveMQ Documentation.

If the Mule application is run again, it should start up without errors and the following can be seen in the console:

On row 7 of the above log fragment, we can see that an embedded instance of ActiveMQ is (again) started.

Finally I just want to add that the “create=false” parameter is not necessary if you just want to customize the embedded ActiveMQ broker within a Mule application – ActiveMQ is smart enough not to start up a second broker instance if one already exists at the same host.
Also, the automatic starting of an embedded broker instance is specific to ActiveMQ and will not happen when using other JMS brokers with Mule unless implemented by the broker.




Leave a Reply

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