This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Child pages
  • Plugin and plugins group
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 19 Next »

Apache Geronimo is now assembled completely out of plugins including the server configuration files, in this section we will explain the overview of plugin system and introduce concept of plugin groups betaken starting from v2.2.

Plugin basics

A geronimo plugin consists of a classloader specification, optional classes, optional service or component configuration, and information about how to install it in Geroninimo. The classloader specification and service configuration is specified in a Geronimo plan (and possibly other plans such as a javaee spec DD or annotations). The information about how to install the plugin is provided in the META-INF/geronimo-plugin.xml file. This file includes details such as the category and description, dependency information showing what else needs to be installed with this plugin, information about files to be unpacked on installation, and configuration information showing how and when the plugin will be started. Before looking at the more complicated aspects of the plugins lets look at a simple example of geronimo-plugin.xml. Here is an example for the jetty web container:

First we see fairly obvious cataloging information:

xmlsolid Geronimo Configs :: Jetty 6 Jetty Geronimo Jetty Web Server integration. The Apache Geronimo development community The Apache Software License, Version 2.0 ]]>

Each geronimo-plugin.xml can specify information for many versions of the "same" plugin, so the plugin-artifact element specifying information for one version can occur multiple times. Here there is just one. First we see the plugin moduleId and the list of dependencies that will be installed if not already present.

xmlsolid org.apache.geronimo.configs jetty6 2.1-SNAPSHOT car 2.1-SNAPSHOT 1.5 org.apache.geronimo.configs j2ee-server 2.1-SNAPSHOT car org.apache.geronimo.configs server-security-config 2.1-SNAPSHOT car org.apache.geronimo.configs transaction 2.1-SNAPSHOT car org.apache.geronimo.modules geronimo-jetty6 2.1-SNAPSHOT jar org.apache.geronimo.configs clustering 2.1-SNAPSHOT car org.slf4j slf4j-api 1.4.3 jar org.slf4j slf4j-jcl 1.4.3 jar org.mortbay.jetty jetty 6.1.5 jar org.mortbay.jetty jetty-ajp 6.1.5 jar org.mortbay.jetty jetty-sslengine 6.1.5 jar org.mortbay.jetty jetty-util 6.1.5 jar org.apache.geronimo.configs webservices-common 2.1-SNAPSHOT car ]]>

Now we see the list of repositories this plugin is expected to be available from. We normally include the local maven repository to make developing plugins easier.

xmlsolid~/.m2/repository/ ]]>

Here we see the prototype for plugin customization. The config.xml file has a section for each module or plugin it knows about and the contents of the config-xml-content in geronimo-plugin.xml are copied into such an element in config.xml. Note the use of substitution variables such as ${ServerHostname}.

xmlsolid $\{ServerHostname\} $\{HTTPPort + PortOffset\} $\{HTTPSPortPrimary + PortOffset\} $\{ServerHostname\} $\{AJPPort + PortOffset\} $\{HTTPSPortPrimary + PortOffset\} $\{ServerHostname\} $\{HTTPSPort + PortOffset\} ]]>

Here we see the default values of the substitution variables. These are copied into the file; you are expected to modify these by hand as necessary.

xmlsolid8080 8009 8443 JettyWebContainer jetty6 ]]>

Missing from this example is the <artifact-alias> element which can be used to replace one plugin by another. For instance you can switch databases by deploying postgres-system-database and specifying <artifact-alias key="org.apache.geronimo.configs/system-database/2.1-SNAPSHOT/car">org.apache.geronimo.configs/postgres-system-database/2.1-SNAPSHOT/car</artifact-alias>

xmlsolid ]]>

One of the more obvious parts of Geronimo is the repository which contains jars as well as plugins. However the plugins by themselves don't do anything; we need some information about which ones to start and how to customize them in order to get a functioning server. This kind of information is normally stored in configuration files in the var/config directory such as config.xml, and There are several "servers" you can start in a normal Geronimo installation, such as the "server", the app client container, the deployer, and the jsr88 tool. The plugin system abstracts this idea of a "server instance" with a ServerInstance gbean that specifies the attribute store (relating to the config.xml and config-substitutions.xml files) and artifact resolver (relating to the file). So the plugin system requires that you set up ServerInstances for all the kinds of servers you expect to start in a Geronimo installation. For instance, the normal Geronimo setup includes these:

xmlsolid default AttributeManager ArtifactResolver offline OfflineAttributeManager ArtifactResolver ServerInfo true var/config/offline-deployer-config.xml var/config/ org.apache.geronimo.config.substitution. client AttributeManager ClientArtifactResolver ArtifactManager var/config/ ServerInfo jsr88 Jsr88AttributeManager ArtifactResolver ServerInfo true var/config/jsr88-configurer-config.xml var/config/ org.apache.geronimo.config.substitution. ]]>

By default, plugins are installed into the default server instance. If you need to install into a different instance you can specify this in the config-xml-content, config-substitution, and artifact-alias elements. Here's an example from client-transaction, showing how it redirects any dependencies to the server transaction plugin to itself.

xmlsolidorg.apache.geronimo.configs/client-transaction/2.1-SNAPSHOT/car org.apache.geronimo.configs/client-transaction/2.1-SNAPSHOT/car ]]>

Plugins group

Plugin group

Look into Administering plugins on how to manage a plugin.

  • No labels