...
Geronimo now 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. This topic is described as Creating deployment plans in details.
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.
Deploying assets via the administration 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:
Deploying assets from the command prompt
The Geronimo command line can be used to invoke the deployer tool, which is a Java application that manages Java EE artifacts, 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. More Geronimo deployer information and details can be found here:
Deploying assets via GShell
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:
Performing 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:
Deploying 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:
Performing 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:
...