7.2. Easy Configuration and Deployment Using the Console

The fastest way to configure a JMS resource group is to use the console. The overall process is to configure the connection to the JMS server, add any number of connection factories and destinations, and then review and deploy the resource group. The section walks through that process.

[Warning]Warning

The console features described here are available in Geronimo starting with version 1.0.1.

To begin with, start Geronimo and point your browser to the console, which is typically at a URL like http://localhost:8080/console/. This brings up the login screen:

Figure 7.1. Console: Login

Console: Login

The default login is username "system" and password "manager" (this can be changed in var/security/users.properties and var/security/groups.properties -- for more detail see Chapter 9, Security Configuration [DRAFT (1.0-pre)]).

7.2.1. JMS Resource Group List

To begin working with JMS resource groups, select the JMS Resources link in the left-side navigation bar:

Figure 7.2. Console: JMS Resource Group List

Console: JMS Resource Group List

This screen lists the available JMS resource groups. For each group, it shows the group name followed by the name of the configuration that resource group was deployed in, and then a list of JMS resources (connection factories and destinations) included in that group. From here you can create a new JMS resource group using the links under Create a new JMS Resource Group at the bottom of the screen.

7.2.2. Creating a new JMS Resource Group

If you select one of the known JMS providers (currently only ActiveMQ), then the console will skip straight to the initial configuration screen. Otherwise, the process begins by selecting a JMS provider.

7.2.2.1. Select JMS Provider RAR

If you don't select one of the pre-configured JMS providers, you'll need to start by selecting the JMS provider RAR. A JMS server vendor may provider their own RAR, or you may find a third-party RAR know to be able to connect to a particular JMS server product. In either case, the RAR should be installed in the Geronimo repository (e.g. saved to a file such as repository/vendor/rars/some-jms-provider-1.0.rar).

Figure 7.3. Console: Select JMS Provider

Console: Select JMS Provider

This screen gives you a list of the RAR files in the repository to select from. Pick the RAR file for your JMS provider, and click Next to advance to the initial configuration screen.

7.2.2.2. Initial Configuration

This configuration screen is driven by the configuration parameters for the selected JMS provider RAR, but normally the settings here are used to identify the server to connect to:

Figure 7.4. Console: JMS Resource Group Configuration

Console: JMS Resource Group Configuration

The one field that's always present on this screen is:

FieldDescription
Resource Group NameA unique name used to identify this resource group. This is how the group is listed in the console, and it will also be needed by message-driven beans that use this resource group to connect to the JMS server.

All the other fields on this screen vary according to the selected JMS provider. Figure 7.4, “Console: JMS Resource Group Configuration” shows the settings for ActiveMQ, which is the most common JMS provider used with Geronimo.

From here, click the Next button to move on to the resource group progress screen.

7.2.2.2.1. ActiveMQ Configuration Settings

The configuration settings for this screen for the ActiveMQ JMS provider are:

FieldDescription
ServerUrlThe URL used to connect to the JMS server. Normally this is tcp://localhost:61616 though for a custom ActiveMQ server configuration you can change the URL to refer to a different host or port, or even to use a different protocol entirely.
UserNameThe user name used to connect to the ActiveMQ server. For the ActiveMQ server that runs as part of Geronimo, this is normally geronimo.
PasswordThe password used to connect to the ActiveMQ server. For the ActiveMQ server that runs as part of Geronimo, this is normally geronimo.
ClientidA JMS client ID used for any connections to the ActiveMQ server. Normally it's better not to specify this for the entire resource group (e.g. leave it blank here).
UseEmbeddedBrokerIf set to true, the resource group will start a new ActiveMQ broker to connect to. Normally this is not what you want since Geronimo already runs a configurable ActiveMQ broker, so this is usually set to the default value of false.
UseInboundSessionIf true, both inbound and outbound sessions will share a single connection to conserve resources. This is normally not what you want, so this is usually set to the default value of false.
BrokerXmlConfigIf UseEmbeddedBroker is set to true, this value identifies an XML configuration file with the configuration settings that the broker should use (otherwise, it is ignored). By default, this file should be on the class path (so any path information would be applied within JARs on the class path, etc.). You may also specify a full URL (e.g. starting with http:// or file:/) to identify a file elsewhere.

7.2.2.3. Create Resource Group Progress

The next screen display the connection factories and destinations created for the resource group so far. The first time you get here, it just displays some help text as nothing has been created yet:

Figure 7.5. Console: JMS Resource Group Progress (First Time)

Console: JMS Resource Group Progress (First Time)

At this point, you can use the Add Connection Factory or Add Destination buttons to add resources to the resource group.

After you create each connection factory or destination, you'll return to this screen and see a list of the progress so far:

Figure 7.6. Console: JMS Resource Group Progress

Console: JMS Resource Group Progress

The summary shows the resources added to the group so far. In addition to the buttons to add new resources, you can select Show Plan to see the Geronimo deployment plan for the resource group, or Deploy Now to finalize the resource group and deploy it to the current Geronimo server.

7.2.2.4. Add Connection Factory

To add a connection factory to the resource group, you must first select the connection factory type. Different JMS providers may support different types of connection factories, but the standard options are:

  • javax.jms.ConnectionFactory (supports connections to both Topics and Queues)

  • javax.jms.TopicConnectionFactory (supports connections to Topics only)

  • javax.jms.QueueConnectionFactory (supports connections to Queues only)

Figure 7.7. Console: Select JMS Connection Factory Type

Console: Select JMS Connection Factory Type

To proceed, select the desired JMS Factory Type and click Next. This brings up the configuration screen for the selected connection factory type:

Figure 7.8. Console: Configure JMS Connection Factory

Console: Configure JMS Connection Factory

The standard settings here are:

FieldDescription
Connection Factory NameA unique name for this connection factory. Applications that create a resource reference to the connection factory will need to use this name to refer to it.
Transaction SupportDefaults to the transaction support declared by the JMS provider's RAR. Normally this should not be changed.
Pool Min SizeThe smallest number of connections that this connection factory should have open at any time. The default is 0.
Pool Max SizeThe largest number of connections that this connection factory should have open at any time. If there are more clients than open connections, the pool will grow to its maximum size, and after that some clients will simply wait for a connection to be returned to the pool. The default is 10.
Blocking TimeoutHow long a client will wait for a connection to become available, if all connections in the pool are in use and the pool is at its maximum size. After this amount of time elapses with no connection available, the client will receive an Exception indicating that no connections are available. The default is 5000 (in other words, 5 seconds).
Idle TimeoutIf a connection in the pool has gone this long without being used, it will be closed and the pool will shrink. The default is 15 (minutes).
[Note]Note

Some JMS providers may offer additional configuration parameters for their connection factories. However, ActiveMQ uses only the standard settings described here.

From here, you can click Next to return to the resource group progress screen (see Section 7.2.2.3, “Create Resource Group Progress”).

7.2.2.5. Add Destination

To add a destination to the resource group, you must first select the destination type. The standard options are:

  • javax.jms.Topic

  • javax.jms.Queue

Figure 7.9. Console: Select JMS Destination Type

Console: Select JMS Destination Type

To proceed, select the desired JMS Destination Type and click Next. This brings up the configuration screen for the selected destination type:

Figure 7.10. Console: Configure JMS Destination

Console: Configure JMS Destination

The one field that's always present on this screen is:

FieldDescription
Message Destination NameA unique name used to identify this destination. This will be needed by JMS clients or message-driven beans to send or receive messages using this destination.

All the other fields on this screen vary according to the selected JMS provider. Figure 7.10, “Console: Configure JMS Destination” shows the additional setting for ActiveMQ, which is the most common JMS provider used with Geronimo.

From here, you can click Next to return to the resource group progress screen (see Section 7.2.2.3, “Create Resource Group Progress”).

7.2.2.5.1. ActiveMQ Destination Configuration

The only destination configuration setting for the ActiveMQ JMS provider is:

FieldDescription
PhysicalNameWhile the Geronimo configuration uses the Message Destination Name to refer to this destination, you can use this setting to actually map that to a destination with a different name in the underlying JMS server. There's not normally any reason to do this, so the PhysicalName is usually set to be the same as the Message Destination Name. It may be helpful if for some reason you don't want to change the deployment plan for an application but you still want to point it to a different underlying destination.

7.2.3. Generate a Plan for an Application or Client Scoped Resource Group

The JMS features in the console can't update an application or client configuration. However, they can generate a deployment plan that can be used elsewhere to either deploy the resource group with the command-line tools, or to include the plan in an application or client module.

To do this, follow the normal process to create a resource group outlined in Section 7.2.2, “Creating a new JMS Resource Group”. From the progress screen, select the command to Show Plan to bring up the plan screen:

Figure 7.11. Console: JMS Resource Group Deployment Plan

Console: JMS Resource Group Deployment Plan

This screen shows the deployment plan that was generated based on the selections made on the previous screens. It also provides a command that could be used to deploy the resource group on the command line, as well as providing a simple procedure to add the resource group to an EAR as an application-scoped group.

The main step to take from this screen is to copy the entire contents of the Deployment Plan text area (using Ctrl-A or a similar shortcut to be sure). The next three sections discuss the different ways to use this plan.

[Tip]Tip

If you plan to deploy more than one resource group in the same server using this plan, be sure to change the configId attribute in the top connector element, as well as the resourceadapter-name, the connectiondefinition-instance name for any connection factories, and the adminobject-instance message-destination-name for any destinations.

7.2.3.1. Deploy via Command-Line Deploy Tool

To deploy via the command-line deploy tool, save the plan to a file on disk. Then that file can be used along with the listed RAR file to deploy the pool. (Note that the RAR file may be different for different JMS providers, but the RAR file displayed on the screen in Figure 7.11, “Console: JMS Resource Group Deployment Plan” is always the correct one based on the way the resource group was configured.)

For example, if the plan was saved as GERONIMO_HOME/jms-resources.xml, and it was a standard resource group using the RAR file activemq/rars/activemq-ra-3.2.1.rar, then a deploy command might look like this:

java -jar GERONIMO_HOME/bin/deployer.jar deploy \
    GERONIMO_HOME/jms-resource.xml \
    GERONIMO_HOME/repository/activemq/rars/activemq-ra-3.2.1.rar

7.2.3.2. Deploy as Application-Scoped Resource Group

To deploy the resource group as part of an EAR, save the plan to a file in the EAR, and copy the RAR file into the EAR as well. Again, note that the RAR file may be different for different JMS providers, but the RAR file displayed on the screen in Figure 7.11, “Console: JMS Resource Group Deployment Plan” is always the correct one based on the way the resource group was configured.

The next step is to create or update the J2EE deployment descriptor and Geronimo EAR deployment plan to include the new module. The Geronimo deployment plan will also use an alt-dd element to indicate that the deployment plan for the RAR is actually in the EAR but not in the RAR file itself. For full details on this procedure, see Section 7.3.2.2, “Application-Scoped Deployment”.

7.2.3.3. Deploy as Client-Scoped Resource Group

To deploy the resource group as part of an application client module, you'll need to copy the plan content into the client deployment plan, and refer to the correct RAR file from the client deployment plan as well. Again, note that the RAR file may be different for different JMS providers, but the RAR file displayed on the screen in Figure 7.11, “Console: JMS Resource Group Deployment Plan” is always the correct one based on the way the resource group was configured.

For full details on this procedure, see Section 7.3.2.3, “Client-Scoped Deployment”.