Versions Compared

Old Version 15

changes.mady.by.user Tim McConnell

Saved on

compared with

New Version Current

changes.mady.by.user Jarek Gawor

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin

...

What

...

changed ??

From a deployment perspective there has been two four significant enhancements to the 2.1.1 version of the Geronimo server. :

  1. The first is deployment using GShell

...

  1. . GShell is a command-line processing environment that can be used for the execution of Geronimo commands. GShell is an extensible environment and includes support for editing, command history, and tab completion. Deployment using GShell is described here: GShell.

  2. The second is deployment to a clustered farm of Geronimo servers. WADI can now be used to support clustering of web applications for Geronimo configurations which use the Tomcat Web Container (WADI support for Jetty was in previous releases). Applications can be deployed to administratively-defined groups of Geronimo servers. Deployment to a clustered farm is described here: Farming.

  3. Geronimo now provides a Plan Creator that automatically generates the necessary deployment plans based on the standard deployment descriptors and annotations, and allows deployment of the corresponding module from which the plans are generated.

  4. Finally, starting with Geronimo 2.1 the servers are assembled entirely out of plugins. Plugins can now be used to extend the functionality of Geronimo itself, install applications that have been packaged as plugins, create custom assemblies of the Geronimo server using Maven or extracting the plugins from an existing server. Plugin information is described here: Plugin infrastructure.

Deployment Options

...

Standard command line

The deployer application Geronimo command line can be used to invoke the deployer tool, which is a Java application that manages J2EE Java EE artifacts and , GBean components, and plugins in the Geronimo server. If Geronimo is running, it will connect to the server and perform its action through the server's deployment service. If it cannot find a running server, it will throw an error stating it could not connect to the server or the server is unavailable.

The deployment tool can be started by using the java -jar to invoke the main class in <geronimo_home>/bin/deployer.jar.

Typically, the deployment tool is started by just using the deploy script, but you can also run the application by starting a Java virtual machine using the following syntax:

java -jar deployer.jar <general_options> <command> <command_options>

where <general_options> specify common options that apply to all commands and control how the application behaves, <command> is a command name that specifies the action to be performed, and <command_options> are options unique to the command specified.

General options

This section lists all the available general options for the Geronimo deployer tool.

...

Wiki Markup
*--uri* <identifier>
Where <identifier> is a Universal Resource Identifier (URI) that specifies how the deployer is to contact the server. If this flag is not specified, the deployer will attempt to contact the server using the standard port on localhost. The identifier must have the following form:
deployer:geronimo:jmx:rmi:///jndi/rmi:\[//host\[:port\]]/JMXConnector
where <host> is replaced with the host name or TCP/IP address of the system where the server is running and <port> is replaced with the port number where the server is listening. If unspecified, localhost and the default port will be used.
\\ 
\\

...

More Geronimo deployer information and details can be found here:

GShell command line

GShell is a command-line processing environment that can be used for the execution of Geronimo commands. GShell is an extensible environment and includes support for editing, command history, and tab completion. A number of Geronimo administrative commands have been implemented using GShell. The old administrative scripts (e.g. geronimo.sh/.bat, deploy.sh/bat, etc) are still available. However, over time, we will be moving our administrative command support to be solely GShell-based. GShell can also be used to install plugins to the Geronimo server. More GShell information and details can be found here:

Clustered deployment

WADI can now be used to support the replication of HTTP Session state among multiple Geronimo servers. In previous releases of Geronimo, WADI could only be used along with the Jetty configuration of Geronimo. WADI can now be used with Tomcat configurations of Geronimo. In addition to the new session replication support, applications can now be deployed to administratively-defined groups of Geronimo servers. This makes it easier to manage a single application across a number of Geronimo servers. More information and details about clustered deployment can be found here:

Plugins

Starting with Geronimo 2.1 the servers are assembled entirely out of plugins. Plugins can now be used to extend the functionality of Geronimo itself, install applications that have been packaged as plugins, create custom assemblies of the Geronimo server using Maven or extracting the plugins from an existing server. Deployment and installation of plugins is now available from the Geronimo commmand line, GShell, and the Geroniom Admin Console. More information can be found below:

Console

The Geronimo Administration Console can also be used to deploy and undeploy new applications and plugins. More information and details can be found here:

GEP - Eclipse

The Geronimo Eclipse Plugin can also be used to deploy and undeploy new applications to a Geronimo server, which may be running either inside or outside of the Eclipse environment. More information and details can be found here:

Hot deployment

The directory structure of an installed Geronimo server includes a <geronimo_home>/deploy subdirectory. This subdirectory is where the Geronimo "hot deployer" will regularly check for new artifacts to be deployed, modified artifacts to be redeployed, or deleted artifacts to be undeployed. Modules copied to the hot deploy directory will be automatically deployed to the Geronimo server, modules updated in the hot deploy directory will be redeployed to the server, and any modules deleted from the hot deploy directory will be undeployed from the server. Note that there are a couple of stipulations when using Geronimo hot deployment capability:

  1. Geronimo-specific deployment plans must be packaged with the module to be deployed; they cannot exist external to the module.

  2. The Geronimo server must be running when modules are deleted from the hot deploy directory; otherwise they will not be deleted when the server is restarted.

Plan Creator

Geronimo provides a Plan Creator wizard that automatically generates the necessary deployment plans based on the standard deployment descriptors and annotations, and also allows the deployment of the corresponding module from which the plans are generated. More information, details, and detailed examples can be found here:

Annotations

Every module that you install in Geronimo, whether it is a service, application, resource, etc., can be configured via a deployment plan. These deployment plans are XML files based on XML Schemas containing the configuration details for a specific application module or component. The Java EE 5 specification defines standard deployment descriptors such as web.xml, application.xml, etc. The Java EE 5 specifications also allows the usage of annotations directly in the Java code to mitigate the development burdens associated with creating Java EE 5 applications.

Annotations in the Java EE specifications is a new metadata facility where many java entities such as classes, fields, packages, methods, etc. can be decorated with annotations. These declarations can reduce, and in many cases eliminate entirely, the necessity of using deployment plans. When both annotations and a declarations in a deployment plan are provided the whe declarations in the deployment plna will take precedence. This allows changes to the deployment characterics of Java EE 5 modules without having to change the code.

Geronimo as a Java EE 5 certified application server supports all the annotations in the Java EE 5 specifications. These annotations are listed and described below, along with the corresponding Java EE 5 specification, and the deployment plan XML element(s) they can replace (if applicable):

Deployment Plans

Deployment plans

Commands

The available commands for the Geronimo deployer tool are listed below:

Additionally, you can type help for further details on a given command, the syntax is as follows:

java -jar deployer.jar help <commands>

...

Use the deploy command to add and start a new module. The deploy command has the following syntax:

java -jar deployer.jar <general_options> deploy <module> <deployment_plan>

The <module> specifies the application file name and location. The <deployment_plan> specifies the file name and location of the XML with the deployment plan. Sometimes the application module already has included in the package a deployment plan or the application is so simple that does not require any deployment plan, in these cases this parameter can be omited.

A module file can be one of the following:

  • J2EE Enterprise Application Archive (EAR) file
  • J2EE Web Application Archive (WAR) file
  • J2EE Enterprise JavaBean Archive (JAR) file
  • J2EE Java Resource Archive (RAR) file

If the server is not currently running at the time of deploying the application, the module will be marked to start next time the server is started.

The most common <general_options> would be --user and --password. The --inPlace option allows you point to and deploy an application directly from a directory external to Geornimo without the need for even packaging the application. In other words, you can have an application running in Geronimo but that application may be anywhere else on the file system.

To use this option you should type:

java -jar deployer.jar <general_options> deploy --inPlace <app_home>

Where <app_home> indicates the home directory where you have your application (exploded).

You can also deploy applications if Geronimo is not running by using the --offline option, the syntax for this command would be:

java -jar deployer.jar <general_options> --offline deploy <module>

Off course, you can also combine --offline and --inPlace

java -jar deployer.jar <general_options> --offline deploy --inPlace <app_home>

...

Use the login command to save the username and password for the current connection to the file .geronimo-deployer in the current user's home directory. Future connections to the same server will try to use this saved authentication information instead of prompting where possible.

This information will be saved separately per connection URL, so you can specify --url or --host and/or --port on the command line to save a login to a different server.

The login command has the following syntax:

java -jar deployer.jar --user <user_name> --password <password> login

So, next time you run a different command that originally required user name and password, you can run the command directly, for example:

deploy list-modules

Warning

Even when the login information is not saved in clear text, it is not secure either. If you want to save the authentication securely, you should change the .geronimo-deployer file in your home directory so that nobody else can read or write it.

...

Use the redeploy command to stop, replace and restart a module that has been deployed before. The redeploy command has the following syntax:

java -jar deployer.jar <general_options> redeploy <module> <deployment_plan>

Just like the deploy command, the redeploy command accepts the following modules file types:

  • J2EE Enterprise Application Archive (EAR) file
  • J2EE Web Application Archive (WAR) file
  • J2EE Enterprise JavaBean Archive (JAR) file
  • J2EE Java Resource Archive (RAR) file

Typically, both a module and a plan are specified. If the module contains a plan or if a default plan can be used, the plan can be omitted. However, if a plan is specified in this case, it overrides the other plans. If the plan references a server component already deployed in the server's environment, the module is omitted.

...

Use the start command to start a previously deployed module. The start command has the following syntax:

java -jar deployer.jar <general_options> start <moduleIDs>

Where <moduleIDs> is a list of one or more modules (configID) separated by blank space. The module identification (or ConfigID) is defined at deployment time in the respective deployment plan for each module previously deployed.

...

Use the stop command to stop a running module. The stop command has the following syntax:

java -jar deployer.jar <general_options> stop <moduleIDs>

Where <moduleIDs> is a list of one or more modules (configID) separated by blank space. The module identification (or ConfigID) is defined at deployment time in the respective deployment plan for each module previously deployed.

...

Use the undeploy command to stop and remove a module (running or not) and its deployment information from the server. The undeploy command has the following syntax:

java -jar deployer.jar <general_options> undeploy <moduleIDs>

Where <moduleIDs> is a list of one or more modules (configID) separated by blank space. The module identification (or ConfigID) is defined at deployment time in the respective deployment plan for each module previously deployed.

This command has the same ability as with deploy to uninstall applications when the server is not running, this command has the following syntax:

java -jar deployer.jar <general_options> --offline undeploy <moduleID>

...

Use the distribute command to add a new module to the server. This command does not start the module nor mark it to be started in the future. The distribute command has the following syntax:

java -jar deployer.jar <general_options> distribute <module> <deployment_plan>

Just like with the deploy command, <module> specifies the application file name and location. The <deployment_plan> specifies the file name and location of the XML with the deployment plan. Sometimes the application module already has included in the package a deployment plan or the application is so simple that does not require any deployment plan, in these cases this parameter can be omited.

A module file can be one of the following:

  • J2EE Enterprise Application Archive (EAR) file
  • J2EE Web Application Archive (WAR) file
  • J2EE Enterprise JavaBean Archive (JAR) file
  • J2EE Java Resource Archive (RAR) file

...

Use the list-modules command to list all available modules on the server, note that for running this command the server must be running. The list-modules command has the following syntax:

Wiki Markup
*{{java -jar deployer.jar <general_options> list-modules \[\-\-all|\-\-started|\-\-stopped\]}}*

  • --all : is used by default when no other option is specified. It will list all the available modules.
  • --started : this option will list only the modules that are running.
  • --stopped : this option will list only the modules that are not running.

...

Use the list-targets command to lists the targets known to the server you have connected to. The list-targets command has the following syntax:

java -jar deployer.jar <general_options> list-targets

In the case of Geronimo, each configuration store is a separate target. Geronimo does not yet support clusters as targets.

...

Use the install-plugin command to install a Geronimo plugin previously exported from a Geronimo server or downloaded from a repository. A Geronimo plugin can be an application, a configuration such data sources and drivers or a combination. The install-plugin command has the following syntax:

java -jar deployer.jar install-plugin <plugin_file>

...

Use the search-plugins command to list all the Geronimo plugins available in a Maven repository. The search-plugins command has the following syntax:

java -jar deployer.jar search-plugins <maven_repository_URL>

Back to top

2. GShell command line

3. Clustered deployment

4. Plugins

5. Console

6. GEP - Eclipse

Annotations

Annotations

Deployment Plans

Deployment plans

    • Deployment plan wizard
    • geronimo-web.xml
    • geronimo-application.xml
    • geronimo-ra.xml
    • geronimo-application-client.xml
    • openejb-jar.xml
    • datasources
    • messaging
    • security

...