Getting Acquainted with the Deployer


You will find the binary of the deployer in the bin directory of your Geronimo distribution. The code is contained in a single JAR file:

 deployer.jar

To run the deployer, you can issue the following command from the Geronimo installation directory:

 java –jar bin/deployer.jar  <options> <command>  <command options>

The deployer.jar file contains only the client portion of the deployer implementation. During regular operations, it will connect to a Geronimo server instance and use the server portion of the online deployer to carry out its work. The module that must be running on the server to enable run-time deployment is called geronimo/online-deployer/1.1/car. This configuration is started by default when you start a Geronimo server instance. This configuration is the server-side mechanism that enables you to deploy modules to a server instance. In addition to online-deployment, offline deployment (essentially installation) to the local host is supported by the deployer without the need for an instance of the server running.

With Geronimo1.1, the online deployer (geronimo/online-deployer/1.1/car module) delegates to other deployer modules to do the actual deployment. The selection of deployer depends on the type of module being deployed. For a J2EE server, you must ensure that the following deployer modules are running:

  • geronimo/j2ee-deployer/1.1/car

  • geronimo/axis-deployer/1.1/car

  • geronimo/client-deployer/1.1/car

  • geronimo/openejb-deployer/1.1/car

  • geronimo/tomcat-deployer/1.1/car or geronimo/jetty-deployer/1.1/car

  • geronimo/geronimo-gbean-deployer/1.1/car

If you look in the bin directory of the distribution, you will find a deploy.bat (or deploy.sh for *nix) script for starting the deployer. You may use this script instead of invoking the self-contained JAR directory. Following is the syntax for this script file:

 deploy  <options> <command>  <command options>

Deploying Modules to a Geronimo Server Instance

Some typical modules that you may deploy to Geronimo via the command-line deployment tool include the following:

  • Servlets and JSPs in the Web-tier via a WAR file

  • EJB JAR files

  • Complete multi-tier enterprise application combining WARs, EJB JAR files, and other resources

  • J2EE Connector Architecture (JCA) connectors and resources

  • Client applications using the Geronimo client application container

In each of these scenarios, the action of deploying a module involves the file transfer of the archive into the repository, parsing the deployment descriptors and deployment plans, and configuring the components (GBeans) on the server.

You deploy a module to Geronimo by supplying the following:

  • A binary code archive (JAR, WAR, EAR, and so on)

  • A deployment plan

Depending on your situation, you may supply only a binary archive, only a deployment plan, or both a binary and a deployment plan.

You supply a binary code archive only when the default J2EE deployment descriptor, embedded as a part of the archive, is sufficient for the deployment of the archive. In addition, Geronimo-specific deployment plans may also be embedded into the archive. You may want to embed Geronimo-specific deployment plans into the archive for convenience of deployment, especially in situations where the need to customize the plans is minimal. For example, deploying progeron.ear in Chapter 2 is as simple as the following:

 deploy --user system --password  manager progeron.ear

Typically, you supply both a binary archive and a Geronimo-specific deployment plan when you want to control the deployment with a custom deployment plan. This can be useful when the same archive is often deployed in different scenarios. If the same type of plan is already embedded into the archive, the externally supplied plan will always override the embedded plan. This technique enables you to flexibly deploy the same binary archive in different situations. For example, if you need to deploy the progeron.ear archive with your own customized deployment plan, you can use the following:

 deploy --user system --password manager progeron.ear  mycustom.xml

You supply only a deployment plan for deployment in the case where you are configuring an archive that is already in the repository. This occurs when you are either deploying a previously deployed archive or customizing a system module. A frequently occurring example is the deployment of a new Derby RDBMS database pool (JCA 1.5 connector). Since the archive of Derby database pool connector is already distributed with Geronimo (and already stored in the repository), there is no need to explicitly deploy any archive again. For example, to deploy a database pool with your own deployment plan, you may use the following:

 deploy --user system --manager deploy  mydbpool.xml

The JSR-88 Personality of the Command-Line Deployer

Figure 6-1 shows the core operation of the Geronimo deployer. In Figure 6-1, you can see that the deployer deploys modules to Geronimo server(s). The deployable module can optionally be accompanied by a Geronimo-specific deployment plan.

image from book
Figure 6-1: Geronimo run-time deployer

Ideally, the deployer can be used to deploy modules to one or more Geronimo servers known as targets. Figure 6-1 shows the possibility of deploying to multiple Geronimo servers at once. This capability is very useful, for example, in configurations where a cluster of Geronimo servers may be running.

The run-time deployer is actually coded to the JSR-88 (J2EE Application Deployment) standard. As a JSR-88 deployment tool, it is capable of working with any other JSR-88-compliant servers, simply by switching drivers. In the language of the JSR-88 specification, each of these servers is known as a target. It is anticipated that all JSR-88-compliant servers will supply such a driver to be used by deployer clients. This means that the Geronimo run-time deployer may be used to deploy modules to other non-Geronimo servers. Figure 6-1 shows this possibility - deploying to a non-Geronimo target(s).

Note that JSR-88 has configuration features that are currently not implemented by the Geronimo command-line deployer. These features may be added to the deployer in future releases.

The Benefits of JSR-88

One of the key benefits of JSR-88 is the concrete specification of a set of deployment APIs, allowing any deployment client to work with any compliant server.

Other than the possibility of using the Geronimo command-line deployer with other JSR-88 servers (which is rather uninteresting for Geronimo users) is the possibility of using other clients with the Geronimo server. Figure 6-2 illustrates the JSR-88 plug-in capability.

image from book
Figure 6-2: The interoperable JSR-88-compliant components

In Figure 6-2, the Geronimo command-line deployer is shown connected via a JSR-88 driver. Using this approach, the deployer can be used for any JSR-88-compliant server - and not restricted to Geronimo alone.

The second scenario shown in Figure 6-2 allows modules to be deployed to Geronimo by any JSR-88-compliant client. Imagine an IDE with a built-in JSR-88 client (most IDEs nowadays include a built-in JSR-88 client). It would be able to deploy modules to Geronimo by simply adding the Geronimo JSR-88 driver.

Support for Offline Installation Mode

The Geronimo deployer supports offline installation. In this offline mode, a Geronimo server instance is not running on the local host machine. Figure 6-3 contrasts the “regular” online deployment mode and the special offline mode of operations.

image from book
Figure 6-3: Online deployment versus offline installation

In Figure 6-3, you can see that the deployer collaborates with a running server instance to install and start a module when operating in the online mode. When operating in offline mode however, the repository of the server being deployed to must be local. In this case, the deployer actually deploys to the local repository directly - without the assistance of a server-side implementation.

You can use the offline deployer functionality whenever the following occurs:

  • The Geronimo server is not running on the local host.

  • You use the deployer with the -offline switch during deployment.

For example, if you needed to deploy progeron.ear archive to the local server while the server is not running, you would use the following command:

 deploy --user system --password manager -offline deploy progeron.ear




Professional Apache Geronimo
Professional Apache Geronimo (Wrox Professional Guides)
ISBN: 0471785431
EAN: 2147483647
Year: 2004
Pages: 148

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net