| 4.3. Server Startup and Modules | ||
|---|---|---|
 | Chapter 4. Elements of Geronimo [DRAFT (1.1)] |  |
| 4.3. Server Startup and Modules | ||
|---|---|---|
| | Chapter 4. Elements of Geronimo [DRAFT (1.1)] | |
The available modules are listed in the
geronimo-1.1/var/config/config.xml file along with
some of their configuration settings -- again, each module may represent a
service, a resource, or an application module. Each of those modules is
(under the covers) composed of a series of GBeans, and the
config.xml file has configuration settings at the
GBean level. In the absence of specific directions, when Geronimo starts,
it starts all the modules that were running last time the server was run.
(This is controlled by the same config.xml file,
which is updated whenever there are changes to GBeans or modules.)
The pre-configured modules shipped with Geronimo are listed below.
Note that some of them are started by default, and some others should not
actually be started manually (they are for internal use only). This list
is from the Geronimo-Jetty stack, so a Tomcat build will have slightly
different names (e.g. geronimo/welcome-tomcat/1.1/car
instead of geronimo/welcome-jetty/1.1/car).
Contains the basic services required for Geronimo to operate (such as GBeans for the repository and logging services). This module should always be run. It is started in the default Geronimo distribution.
Handles the RMI registry and naming services, which are additional fundamental services for the J2EE server environment. It is started in the default Geronimo distribution.
Contains the services necessary for Geronimo to act as a J2EE server (such as GBeans for the transaction manager, J2EE management API, and J2EE connector service). This module should be run when Geronimo should be capable of hosting J2EE applications (which for the purposes of this book means "always"). It is started in the default Geronimo distribution.
Provides the core security services for Geronimo, including the administration security realm. This is required for any security features to work, as well as remote administration. It is started in the default Geronimo distribution.
Handles the basic web container, including web application hosting features, network listeners, web application deployer, etc. It is started by default.
Provides the EJB container, responsible for running EJB components in Geronimo. This module is started by default in the J2EE distributions of Geronimo, though it is not included in the Little G distribution.
Provides the web services features for Servlets or EJBs exposed as web services, or J2EE applications acting as clients to remote web services. This module is started by default in the J2EE distributions of Geronimo, though it is not included in the Little G distribution.
Contains basic CORBA configuration that allows code running in Geronimo to act as a CORBA client (calling out to remote CORBA services) or CORBA server (being called by remote CORBA clients). This does not need to be started if CORBA features are not required, and it is not started by default. It is not included at all in the Little G distribution. Note: Geronimo's CORBA implementation requires a Sun Java 1.4.2 VM (though IBM offers a Geronimo-based product with CORBA features that run on the IBM Java VM).
Starts a basic embedded Derby database and network listener. It is required in order to support features like the EJB Timer service and JMS persistence. This is started by default in the J2EE distributions of Geronimo, though it is not included in the Little G distribution.
Starts an ActiveMQ JMS server. This is started by default in the J2EE distributions of Geronimo, though it is not included in the Little G distribution.
Starts a JMS connection factory (that connects to the default ActiveMQ server) and two JMS queues for internal server use. This is started by default in the J2EE distributions of Geronimo, though it is not included in the Little G distribution.
Handles basic deployment operations for Geronimo, including deploying new configurations. This should be running for all but the most locked-down servers. It is started by default.
Expands the geronimo-gbean-deployer to
handle J2EE applications and modules. This should be running for all
but the most locked-down server configurations. It is even used in
Little G, to support EARs so long as they don't contain unsupported
module types (like EJBs, by default).
Handles deployments of web applications using the Jetty web container. It is started by default.
Handles deployments of EJB applications, using the OpenEJB container. This is started by default in the J2EE distributions of Geronimo, though it is not included in the Little G distribution (instead, there's an "unavailable" EJB deployer to handle it if you try to deploy EJBs).
Handles deployments of J2EE web services, using the Axis web services stack. This is started by default in the J2EE distributions of Geronimo, though it is not included in the Little G distribution (instead, there's an "unavailable" web services deployer to handle it if you try to deploy J2EE web services).
Handles deployments of J2EE application clients. This is started by default in the J2EE distributions of Geronimo, though it is not included in the Little G distribution (instead, there's an "unavailable" client deployer to handle it if you try to deploy an application client).
Monitors the geronimo/deploy directory for activity,
deploying any files copied into that directory, redeploying as the
files are updated, and undeploying when the files are removed. This
is an optional service, but it is started by default. It is not
currently included in Little G.
Provides JavaMail features, including a mail session that applications can use. Geronimo provides both the JavaMail framework and a simple SMTP transport. For more advanced SMTP features or POP/IMAP support, you can run a third-party transport on the basic JavaMail framework. This is available but not currently started by default in J2EE distributions of Geronimo, and is not included in Little G.
Supports directories containing arbitrary classes or JARs that can be added to the class path of an application. This can be used to work around the structured approach of the Geronimo repository, and just dump a bunch of JARs in the shared library directory. However, if an application uses this capability, it can't be copied or exported as a plugin, because Geronimo doesn't know what those shared library JARs actually are. Therefore, it's best used while porting existing applications. This module is started by default.
A sample web application that listens on the server root
context (e.g. http://localhost:8080/) and
provides a basic sanity check and some pointers for more
information. This application is optional, and it is started by
default. It must be disabled if you have a different application
that should listen for requests on the root context of "/". This is
started by default in the J2EE distributions of Geronimo, though it
is not included in the Little G distribution.
The web management console application. This provides a
web-based UI for server configuration and administration. The
console is recommended for all but the most locked-down server
configurations. It is started by default at
/console (so the default URL is http://localhost:8080/console/).
This is started by default in the J2EE distributions of Geronimo,
though it is not included in the Little G distribution (because it
is currently hardcoded to support many features like EJB and JMS
that are not available in Little G).
A web application that handles deployment requests when you
run the command-line deploy tool on a machine separate from the
application server. This is recommended for most configurations,
though the deployment tools can still be run locally even if this is
disabled. It is started by default at
/remote-deploy in the J2EE distribution of
Geronimo, though it is not included in the Little G
distribution.
A JAXR/UDDI server implementation, which runs as a web
application. It is optional and started by default at
/juddi in the J2EE distribution of Geronimo,
though it is not included in the Little G distribution.
Should not be started. Used internally by the J2EE application client container.
Should not be started. Used internally by the J2EE application client container.
Should not be started. Used internally by the J2EE application client container.
Should not be started. Used internally by the J2EE application client container.
Should not be started. This is used under the covers in
conjunction with the deployer.jar tool.
Should not be started. This is used under the covers in
conjunction with the shutdown.jar tool.
Should not be started. This is used under the covers in
conjunction with the upgrade.jar tool.
Should not be started. This is used under the covers in
conjunction with the upgrade.jar tool.
![[Tip]](images/tip.png) | Tip |
|---|---|
You can compare the list above to the available modules in the
repository, as well as the modules listed in
|
Individual modules can be started and stopped using the Geronimo deploy tool (however, the deploy tool cannot manipulate specific GBeans within a module). For example, to start two additional modules, once the server is up and running you could issue commands such as:
java -jar bin/deployer.jar start \
geronimo/j2ee-corba/1.1/car
java -jar bin/deployer.jar start \
geronimo/javamail/1.1/carNote that these commands require an administrator login, which defaults to a username of "system" with password "manager". For detailed syntax and more information about the deploy tool, see Section 10.4, “The Deploy Tool”.
Each module must list the other JARs and modules it requires as
dependencies in its deployment plan. That ensures that any dependency
modules will be started, and the module or JAR classes will be added to
the current module's class path. Every deployment plan has an
<environment> element that can be used to list
dependencies. (The specific format of each of the Geronimo application
deployment plans is covered in Part III, “J2EE Applications on Geronimo”.)
| Tip |
|---|---|
With Geronimo 1.1, it is critical that all necessary modules are listed as dependencies. For example, if a web application uses a database connection pool, it must list the database pool module as a dependency. In Geronimo 1.0 an application could automatically see "standalone" modules deployed in the server, but that's no longer true in Geronimo 1.1. |
Example 4.3. Application Dependencies
This is a sample Geronimo deployment plan header for a web application. The web application uses MyWebApp as the key part of its module ID, and lists two RARs as dependencies -- AppDatabasePool and AppJMSResources:
<web-app xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.1">
<environment
xmlns="http://geronimo.apache.org/xml/ns/deployment-1.1">
<moduleId>
<artifactId>MyWebApp</artifactId>
</moduleId>
<dependencies>
<dependency>
<artifactId>AppDatabasePool</artifactId>
<type>rar</type>
</dependency>
<dependency>
<artifactId>AppJMSResources</artifactId>
<type>rar</type>
</dependency>
</dependencies>
</environment>
...That means that the database pool and JMS resources will always be started before the web application, and the application can declare and use resource references and message destination references to access those resources.
| Tip |
|---|---|
To avoid worrying about dependencies altogether, you can include all your application modules in an EAR, and configure the necessary Geronimo resources in the EAR as well. That will make sure the application modules and all the resources they require are deployed as a single unit. However, that approach also prevents the sharing of a resource (such as a database connection pool) between multiple applications. |
Geronimo usually adds some additional dependencies to each module
automatically -- for example, a web application gets an automatic
dependency on the web container, to make sure the web container is
started before the web application. These automatic dependencies also
add the J2EE specification APIs to an application's class path, as well
as common libraries such as the commons-logging
logging library.
The deployer tool can be used to add new modules to the Geronimo server. The usual syntax looks like this:
java -jar bin/deployer.jar deploy mymodule.jar
This would deploy and start a new module defined by the archive
mymodule.jar. It will prompt for a username and
password, which default to "system" and "manager" respectively. This
command can be run on any J2EE application module (EJB JAR, WAR, RAR,
EAR, etc.) to create a configuration for it. The server must be running
for this command to work.
In cases where the Geronimo-specific deployment information is stored in a file outside the application archive, an additional parameter can be used to identify the Geronimo deployment plan:
java -jar bin/deployer.jar deploy mymodule.jar \
module-geronimo-dd.xmlAnother deployment option is to copy the module to the geronimo/deploy directory and allow the hot
deployer to notice it and deploy it (this does not work with a Geronimo
deployment plan unless the plan is packaged inside the application
module). The administration console also has a deployment screen.
Generally the command-line deploy tool has a couple advantages: in
addition to handling external plans, it also prints any deployment
errors directly to the terminal where you ran it (as opposed to the hot
deploy tool, where any errors go to the server console and server log
only). However, the command-line deployer does not work when the server
is not running, while the hot deploy directory can at least deploy new
applications during server startup (it doesn't handle undeployment
during startup).
For more deployment options, see Section 10.4, “The Deploy Tool”.
The same deployer syntax can be used to deploy Geronimo service modules in addition to application modules.
| |  | |
| 4.2. The Kernel and GBeans |  | 4.4. Introduction to Deployment |