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

Compare with Current View Page History

« Previous Version 7 Next »

Plugins

Plugins can be system modules, applications, classloader definitions, and plugin groups. The Geronimo server is assemblages of plugins. Assemblies are the different ways you can create a server out of the various pluging available. Starting with Geronimo 2.1 and 2.2, the servers are assembled entirely out of plugins.

Introduction to a plugin

Plugins have an identifier with groupId, artifactId, version, and type. It's possible to have a plugin without a moduleId but this is not currently used.

  • A plugin can define a classloader in which case:
    • A plugin with a classloader can define geronimo services (gbeans) that can use classes in the classloader (and its parents).
    • A plugin can depend on this classloader. For exampple, it can have this classloader as a parent.
    • A plugin can contain classes which are made available in the classloader. This is used mostly for Java EE application plugins, where the application classes are packed in the plugin.
  • A plugin can contain resources that are unpacked into the server upon installation (typically in the var/ directory in a plugin-specific location).
  • A plugin includes a list of dependencies. This is intended to normally be as effective as the classloader dependencies, if there is a classloader.
  • A plugin without a classloader definition still includes a list of dependencies. These are typically used as "plugin groups" to install a set of plugins at once.

Plugins can contain both server functionality and application functionality or both. For instance, you can include a web server configuration in a web application plugin.

Finding a plugin

Plugins are listed in plugin catalogs which contain information about the plugins (typically name and description) and where to get the plugin.
Plugins are normally stored in plugin repositories which act much like maven2 repositories. The most common examples of plugin repositories are the following:

  • Your local maven repository if you have built geronimo or used maven to package plugins.
  • The Apache plugin repository containing all the plugins packages by the Apache Geronimo project.
  • Another geronimo server running the jetty or tomcat plugin-console plugin.

Installing a plugin

You can install a plugin into an existing server in different ways:

  • GShell deploy/list-plugins command
  • Geronimo administrative console
  • Using maven and the geronimo-maven-plugin
    You can also install a plugin into a new server assembly using the car-maven-plugin.
    Note that in all cases the dependency system assure that if you install a plugin, everything needed to run the plugin will also be installed. For instance if you install a Java EE application plugin such as one of the samples into the framework server, openejb, openjpa, the transaction manager and connector framework and the appropriate web container will also be installed as dependencies.

Creating a plugin

  • You can create a plugin as part of a maven build using the car-maven-plugin.
  • You can create a plugin "virtually" by installing a deployed application from a running geronimo server acting as a plugin repository.
  • You can create a plugin using the Geronimo administrative console to create or edit the plugin metadata.

Look in to Plugin infrastructure for more details.

Updating a plugin

At times, you may need to upgrade a plugin or jar version, for instance if a new version of a dependency is released but you cannot rerelease all the artifacts that depend on it. Here are some methods to upgrade jar versions.

Simple jar upgrade

If the jar is to be installed as part of a plugin installation, see the section below. Otherwise, follow these steps. First, if the server is running, stop the server. Second, copy the new jar into the appropriate directory in your geronimo server's repository. For instance:

mkdir -p repository/org/foo/myjar/1.1/
cp ~/newFooJar/myjar-1.1.jar repository/org/foo/myjar/1.1/

Alternatively, the admin console portlet Services->Repository can be used to add artifacts to the server's repository.

Finally, after the new jar is installed in the server's repository, add a line to var/config/artifact_aliases.properties (or the equivalent file, if the server is using a non-standard alias file). For instance, to replace myjar-1.0.jar with myjar-1.1.jar:

org.foo/myjar/1.0/jar=org.foo/myjar/1.1/jar

With this configuration, the server will substitute myjar-1.1.jar for any myjar-1.0.jar dependency.

Upgrading a jar while releasing a plugin

If the jar is installed as part of a plugin installation, you can include configuration upgrade information in the geronimo-plugin.xml. During plugin installation, the upgraded jar will be automatically installed. This is easiest to specify in the car-maven-config configuration in the pom.xml, prior to building the plugin.

<artifact-alias key="org.foo/myjar/1.0/jar">org.foo/myjar/1.1/jar</artifact-alias>
  • No labels