A message broker hosts the destinations (topics and queues), manages delivery, applies options such as transactional delivery and persistent messages, and so on. When configuring the server, you don't create specific destinations, but you can customize things like where persistent messages should be stored and whether the message broker should be clustered.
Since Geronimo starts an ActiveMQ message broker by default, the procedures described in the section are usually not necessary, but they are described in case more extensive ActiveMQ customization is required.
A typical configuration is to deploy a server-wide message broker,
and then attach various application-scoped resources to it. Geronimo
ships with a basic server-wide message broker configuration called
geronimo/activemq-broker/1.1/car. It is started when
Geronimo is started in the default configuration, but if it gets
disabled for any reason, you can manually start it using a command like
this (while the server is running):
java -jar bin/deployer.jar start geronimo/activemq-broker/1.1/car
This configuration includes a TCP transport on port 61616 and a direct transport for clients in the same JVM.
For a more detailed ActiveMQ configuration, you'll use XML snippets to configure the GBeans for the message broker. Depending on how you choose to deploy the broker, you may create a deployment plan to hold these, or you may insert them into the deployment plan for an existing application or module.
![]() | Tip |
|---|---|
GBean configuration and deployment is covered in greater detail in Chapter 18, GBeans: Adding New Services to Geronimo [DRAFT (1.1)]. The current section gives you enough to deploy a custom message broker, but does not cover the full syntax or options for arbitrary Geronimo services. |
A sample GBean configuration looks like this:
Example 7.2. JMS Message Broker Configuration
<dependency>
<groupId>geronimo</groupId>
<artifactId>system-database</artifactId>
<type>car</type>
</dependency>
<dependency>
<groupId>activemq</groupId>
<artifactId>activemq-core</artifactId>
<type>jar</type>
</dependency>
<dependency>
<groupId>activemq</groupId>
<artifactId>activemq-gbean-g1_1</artifactId>
<type>jar</type>
</dependency>
<dependency>
<groupId>activemq</groupId>
<artifactId>activemq-gbean-management-g1_1</artifactId>
<type>jar</type>
</dependency>
<dependency>
<groupId>activeio</groupId>
<artifactId>activeio</artifactId>
<type>jar</type>
</dependency>
<!-- One ActiveMQ Manager should be present in the server at
all times. If the default ActiveMQ broker is running
then this plan doesn't need one, but if this is the only
ActiveMQ broker then it should list the manager GBean. -->
<gbean name="ActiveMQ"
class="org.activemq.gbean.management.ActiveMQManagerGBean"/>
<!-- Message Broker GBeans -->
<gbean name="ActiveMQ"
class="org.activemq.gbean.ActiveMQContainerGBean">
<attribute name="brokerName">
possibly-unique-broker
</attribute>
<reference name="persistenceAdapter">
<name>ActiveMQ.cache</name>
</reference>
<reference name="JMSManager">
<name>ActiveMQManager</name>
</reference>
<dependency>
<name>SystemProperties</name>
</dependency>
</gbean>
<gbean name="ActiveMQ.cache" class=
"org.activemq.store.cache.SimpleCachePersistenceAdapterGBean">
<attribute name="cacheSize">10000</attribute>
<reference name="longTermPersistence">
<name>ActiveMQ.journal</name>
</reference>
</gbean>
<gbean name="ActiveMQ.journal" class=
"org.activemq.store.journal.JournalPersistenceAdapterGBean">
<reference name="serverInfo">
<name>ServerInfo</name>
</reference>
<attribute name="directory">var/activemq/journal</attribute>
<attribute name="journalType">default</attribute>
<reference name="longTermPersistence">
<name>ActiveMQ.jdbc</name>
</reference>
</gbean>
<gbean name="ActiveMQ.jdbc"
class="org.activemq.store.jdbc.JDBCPersistenceAdapterGBean">
<reference name="dataSource">
<name>SystemDatasource</name>
</reference>
</gbean>
<gbean name="ActiveMQ.tcp.localhost.61616"
class="org.activemq.gbean.ActiveMQConnectorGBean">
<attribute name="protocol">tcp</attribute>
<attribute name="host">localhost</attribute>
<attribute name="port">61616</attribute>
<reference name="activeMQContainer">
<name>ActiveMQ</name>
</reference>
</gbean>
<gbean name="ActiveMQ.vm.localhost"
class="org.activemq.gbean.ActiveMQConnectorGBean">
<attribute name="protocol">vm</attribute>
<attribute name="host">localhost</attribute>
<attribute name="port">-1</attribute>
<reference name="activeMQContainer">
<name>ActiveMQ</name>
</reference>
</gbean>
<gbean name="SystemProperties"
class="org.apache.geronimo.system.properties.SystemProperties">
<attribute name="systemProperties">
activemq.broker.disable-clean-shutdown=true
</attribute>
</gbean>This is basically split into two parts, a list of dependencies, and a set of GBeans.
![]() | Warning |
|---|---|
The example above uses the same names as the actual ActiveMQ broker configured in Geronimo. All the full GBean names will come out different so long as the module ID for this module is different, but it may still be a little confusing. Also, make sure to select a different TCP/IP port for the network listener if you don't want to conflict with the built-in ActiveMQ broker. |
The elements in Example 7.2, “JMS Message Broker Configuration” related to dependencies include:
Each dependency identifies either a Geronimo module that this resource group depends on, or a JAR that must be loaded for the resource group to use -- this is generally used for the JMS broker module. This element may be repeated if multiple JARs need to be loaded. The child elements hold the different components of the module ID for the dependency.
In this case, a number of JARs are listed, including ActiveMQ itself and a number of dependencies. By leaving out the version numbers, this plan will work with whatever specific versions are installed.
The rest of the elements in Example 7.2, “JMS Message Broker Configuration” control the GBeans for the JMS Server. There are several JMS GBean types -- the management features, the core JMS Server configuration (or ActiveMQContainer), persistence methods used by the ActiveMQ broker, one or more transports (or ActiveMQConnectors) providing a pathway for JMS resources to communicate with the core JMS Server, and system properties used by ActiveMQ. Each of the GBean definitions has the same overall form, with elements and attributes including:
The overall wrapper for a single GBean configuration
The unique name to use for this GBean. It is combined with some default settings based on the GBean type and deployment style to create a full GBean Name identifying this component. Note that some of the GBeans here include references to each other, so changing the name of a GBean may require updating the references to it to match. Finally, note that every GBean must have a unique name within this plan.
The implementation class for this GBean. There specific values that must be used for this.
Sets a property exposed by the GBean class. When you use an attribute tag, you provide the value as a basic Java type such as String or Integer. The name attribute will be used to identify the setter to invoke on the GBean, the type attribute specifies the data type, and the content of this element is the value to set.
Sets a property exposed by the GBean class. When you use a reference tag, you provide either a gbean-name element with the full GBean Name that identifies another GBean, or a group of child elements that specifically identify certain portions of the GBean name (leaving the rest to use default values).
While that gives you a feel for the structure of the GBean configuration, each of the JMS GBean types requires specific configuration options.
The first GBean in the example handles management features for ActiveMQ. This GBean should be deployed exactly once; list it in a custom broker module only if the default broker will not be used. The configuration that can be performed here includes:
The name may be changed to something other than ActiveMQManager if you like. The broker GBean needs to refer to this one by name, so changes to this will require changed to that.
Note that if the ActiveMQManager is not deployed as part of
this module, the geronimo/activemq-broker/1.1/car
module must be listed as a dependency so the main ActiveMQManager
can be used.
The next GBean in the example creates the core JMS Server. This must be present. The configuration that can be performed here includes:
The name may be changed to something other than ActiveMQ if you like. The connector GBeans need to refer to this one by name, so changes to this will require changed to those.
A name used to identify this ActiveMQ instance.
A pointer to the persistence implementation, which typically involves a back-end data store and a cache on top of it. Normally this GBean refers to the cache, and the cache refers to the underlying persistence mechanism.
A pointer to the Active<Q management interface.
The next GBeans in the example create a persistence implementation that is a cache on top of a journaling system on top of a JDBC data store. Some persistence implementation must be present, and while all these layers are not strictly required, they give a good balance between performance and reliability. The ActiveMQContainer GBean must refer to the topmost persistence GBean, and each persistence GBean refers to the next one down the chain. While each persistence GBean is distinct, they are similar and the configuration options are listed together here:
The name may be changed, though the ActiveMQContainer GBean needs to refer to the topmost persistence GBean by name, and each persistence GBean needs to refer to the next by name, so each GBean needs to be kept synchronized with name changes to the GBean it depends upon.
The number of entries the caching GBeans holds in its cache.
This reference should not be changed, as it allows ActiveMQ to discover other elements of the Geronimo configuration. In this case, the journaling GBean uses it to locate a directory to use for its journal.
The directory (relative to the server directory identified by the ServerInfo service) where the journaling GBean stores its journal.
The format used for the journal.
A pointer to the next GBean in the chain, which this one uses to store persistent data.
The database connection pool that the JDBC persistence GBean uses to communicate with the database. This should be a JCAManagedConnectionFactory GBean, where the name is the name of the database pool.
Once the core JMS Server is available, we need to define one or more methods for JMS resources to contact it. This may include network transports, a direct connection for clients in the same JVM, and more. Whichever transports are provided here will be available when we configure JMS resources later. You'll configure one GBean for each transport -- Example 7.2, “JMS Message Broker Configuration” has one GBean for an in-VM transport, and one GBean for a TCP/IP transport.
The recommended transport types are summarized in Table 7.1, “ActiveMQ Transport Types”. Other transport types are available, but they are generally more suitable for peer-to-peer or cross-language operation instead of a connection from a Java client to a JMS Server.
The configuration that can be performed on an ActiveMQConnector includes:
A unique name for this GBean.
The protocol that clients will use to connect to the JMS Server through this connector. The protocol controls how the connector will listen for client connections.
For network protocols, this is used to select a network
interface to bind to. Normally it is set to
localhost (for local connections only) or
0.0.0.0 (to listen on all available
interfaces).
For network protocols, this is the network port to bind to.
A reference to the core JMS Server.
The GBeans for the message broker can be deployed in any of the three scopes, though normally they're deployed server-wide.
First, create a deployment plan that's simply a wrapper around
the dependencies and GBeans above, and save it to a file such as
message-broker-plan.xml (you can use any name).
The file should look like this:
message-broker-plan.xml
<module xmlns="http://geronimo.apache.org/xml/ns/deployment-1.1">
<environment>
<moduleId>
<artifactId>MyJMSBroker</artifactId>
</moduleId>
<dependencies>
<!-- dependency elements here -->
</dependencies>
</environment>
<!-- gbean elements here -->
</configuration>Next, deploy that with a command like this:
java -jar bin/deployer.jar deploy message-broker-plan.xml
(Note that this command assumes that the server is running.)
To deploy a JMS Server to a single application, you'll add the
GBean definitions to the deployment plan for the application (which
must be packaged as an EAR). This is typically a
META-INF/geronimo-application.xml file in the
application EAR. If you don't already have a Geronimo deployment plan
for the application, you can create one with nothing but the message
broker GBean configuration.
A typical geronimo-application.xml
deployment plan would look like this:
META-INF/geronimo-application.xml
<application
xmlns="http://geronimo.apache.org/xml/ns/j2ee/application-1.1">
<environment>
<moduleId>
<artifactId>MyApplication</artifactId>
</moduleId>
<dependencies>
<!-- dependency elements here -->
</dependencies>
</environment>
...
<!-- gbean elements here -->
</application>Then the application can be packaged and deployed like normal, and the message broker will be started when the application is started.
A client-scoped message broker is configured the same way as an
application-scoped message broker, except the GBean configuration is
inserted into the deployment plan for a single application module
instead of for the application EAR. For example, here's an
geronimo-application-client.xml file including a
JMS Server as part of an client deployment:
META-INF/openejb-jar.xml
<application-client xmlns=
"http://geronimo.apache.org/xml/ns/j2ee/application-client-1.1">
<server-environment
xmlns="http://geronimo.apache.org/xml/ns/deployment-1.1">
<moduleId>
<artifactId>MyClientJSR77</artifactId>
</moduleId>
</server-environment>
<client-environment
xmlns="http://geronimo.apache.org/xml/ns/deployment-1.1">
<moduleId>
<artifactId>MyClient</artifactId>
</moduleId>
<dependencies>
<!-- dependency elements here -->
</dependencies>
</client-environment>
...
<!-- gbean elements here -->
</openejb-jar>For the specific ordering of elements within the different module deployment plans, see Chapter 11, Web Applications (WARs) [DRAFT (1.1)], Chapter 12, Enterprise Java Beans (EJB JARs) [DRAFT (1.0)], and Chapter 14, Client Applications (Client JARs) [IN PROGRESS 1.0].