Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Plugins

Plugins are actually can be system modules. An assembly, then, is a grouping of modules that provides a Geronimo server instance with its feature set, applications, classloader definitions, and plugin groups. The WASCE server is assemblages of plugins. Assemblies are the different ways you can create a server out of the various modules pluging available. Plugins are very dependent and sensitive to server versions. As such, plugins that are compiled against one server version (like Geronimo 2.1) might not deploy or function correctly in new releases (such as Geronimo 2.1.3). Just as you must redeploy your applications when migrating to updated server releases, you must regenerate any existing plugins for different server levels. Last but not least, when installing plugins you need Internet access so the plugin installer can retrieve all the necessary dependencies from the online repositories.

Starting with Geronimo 2.2, the servers are assembled entirely out of plugins.

Starting with Geronimo 2.1 and 2.2, the servers are assembled entirely out of plugins.

What is 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.

How do I find plugins?

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.

How do I install plugins?

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.

How do I create plugins?

  • 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
  • Most plugins are modules, describing a classloader and services and possibly containing classes and resources.
  • Plugins also contain descriptive information and include additional instructions on how the plugin fits into a server.
  • Information about multiple plugins can be collected into a plugin catalog, often located in a maven repository
  • A plugin repository is basically a plugin catalog together with a maven-structured repository containing plugins.
  • Plugins can be installed from a plugin repository into an existing Geronimo server using GShell commands or the Geronimo Administration Console.
  • Plugin metadata for an existing plugin in a Geronimo server can be edited (to some extent) in the administrative console.
  • A new server containing a specified set of plugins can be extracted from an existing server using GShell commands or the Geronimo Administration Console.
  • The dependency system assures that the resulting server has all needed plugins to operate.