Navigating the Services Functional Menus

This section explores the menu options listed in the main category of the Services on the Web console GUI.

Installing Artifacts into the Geronimo Repository

The Geronimo repository is where the server stores and keeps track of the binary executables. It is also the place where Geronimo configurations are stored. For example, you will find the binary JAR files for both Tomcat and OpenEJB in the repository.

Any <dependency> element that you see in a system deployment plan may be referring to some files (called artifacts) in the repository.

The repository, as explained in Chapter 5 stores the binaries and configurations under the repository directory. Every artifact is stored under a directory that match its coordinate. The coordinate consists of (organization/group, artifact id, version, type). This coordinate system is also used for storing configuration of deployed modules - matching the deployed module’s module ID.

All of the binaries stored in the repository are in JAR format but may be named WAR, EAR, RAR, JAR- depending on the type of archive. The general directory hierarchy of the repository is shown in Figure 8-11.

Figure 8-11: Directory hierarchy of the Geronimo repository

In Figure 8-11, note that you can readily identify the organization/group that owns the artifacts by the top-level directory name (sometimes multiple top-level directories). For example, the ActiveMQ binaries are located under the activemq directory in the repository.

The level below the organization is the artifact ID level. In the case of activemq in Figure 8-11, there are three artifacts: activemq-core, activmq-gbean-g1_1, and activemq-gbean-management-g1_1.

Underneath the artifact ID directory level is the version level. In Figure 8-11, the 3.2.4 directory underneath the activemq\activmq-core directory is the version directory.

Finally, you will find the stored JAR file underneath the version directory. In the case of Figure 8-11, the actual artifact is stored as activemq-core-3.2.4.jar.

In the Web console, if you select Services→Common Libraries, you will see the repository viewer portlet. Figure 8-12 shows the Repository Viewer portlet.

Figure 8-12: The Repository Viewer and Installation portlet

Using the Repository Viewer portlet, not only can you see all the individual artifacts that are stored in the repository (including the complete path to the artifact, reflecting its associated coordinate), but you can also add additional artifacts to the repository. Typically, you will only add artifacts to the repository if you need to install code that is integrated as part of the system common library. For example, you may want to add a JDBC driver to an RDMBS that is accessible by all applications running on your Geronimo server.

To install a new artifact, just click the Browse button, then browse to the artifact stored on your disk, then supply its coordinate information (group, artifact ID, version, type), and then click the Install button.

Once an artifact is installed into the repository, any deployed application can refer to it via a <dependency> element that specifies its coordinate. For example, if you deployed a library called tools-3.2.jar with coordinates (wrox, tools, 3.2, jar), it can be referenced as wrox/tools/3.2/jar in a <dependency> element.

Installing Database Pools

J2EE applications deployed in Geronimo may access any RDBMS via JDBC. JDBC operations require a driver specific to the RDBMS that you are connecting to. Geronimo can manage and pool JDBC connections for efficient access to the RDBMS. Internally, Geronimo uses TranQL to provide database connection pooling.

The Database Pools portlet can help you create a Geronimo-managed database pool. Database pools managed by Geronimo can be accessible systemwide or be specific to an application. Only systemwide pools can be edited using the portlet. You can access the database pool configuration portlet by selecting Services→Database Pools. Figure 8-13 shows the Database Pools configuration portlet.

Figure 8-13: The Database Pools configuration portlet

In Figure 8-13, the portlet shows one single systemwide accessible SystemDatabasource pool. You can click the edit link to see or change the configuration parameters of the pool. You can also click the usage link to see how to configure your deployment plans, within a Geronimo-hosted application, to use this database pool.

Using the Geronimo Database Pool Wizard, you can create a new datasource for use systemwide. The wizard will guide you step by step through the process. The binary of the JDBC driver must either be installed previously to the repository (perhaps using the Repository Viewer portlet) or downloaded by Geronimo during the process. The Geronimo console supports automated downloading and installation of a small set of well-known drivers. This set of drivers may change in the future and currently includes drivers downloads for MySQL, PostgreSQL, HSQLDB, Sybase, and so on.

If you are migrating from another server, the Database Pools configuration portlet also allows you to import a database pools configuration directly from the following:

• JBoss 4

• BEA Weblogic 8.1

A step-by-step wizard will guide you through the configuration import process.

Creating JMS Resource Groups

JMS resource groups are grouping of message destinations with its associated connection factory. Message destinations are message queues or topics that JMS applications can send messages to or receive messages from. You can set up new JMS resource groups using the Web console.

Select Services→JMS to access the JMS Resources portlet, as shown in Figure 8-14.

Figure 8-14: Creating JMS resource groups

JMS connection factories are like JDBC drivers; they are JCA connectors. Think of them as binary code that represents drivers to different servers, a message broker in the former case and an RDBMS in the latter case. With Geronimo, a JMS connection factory manages a pool of connections to an ActiveMQ message broker (server). In Figure 8-14, the DefaultActiveMQConnectionFactory is a connector to the Geronimo-hosted instance of the ActiveMQ server.