...

Apache Geronimo v2.1 is now assembled completely out of plugins including the server configuration files, and maven now builds a plugin whenever you "predeploy" a module with a geronimo plan. We'll explain the plugin system features so you can see how to specify installation activities, customization points, and when your plugin will be started, as well as how to access these features in a maven build.

Plugin system overview

...

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 on 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:

...

Each

...

geronimo-plugin.xml

...

can

...

specify

...

information

...

for

...

many

...

versions

...

of

...

the

...

"same"

...

plugin,

...

so

...

the

...

plugin-artifact

...

element

...

specifying

...

info

...

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.

...

...

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.

...

...

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

...

is

...

copied

...

into

...

such

...

an element.

...

Note

...

the

...

use

...

of

...

substitution

...

variables

...

such

...

as

...

${ServerHostname}.

...

...

Here

...

we

...

see

...

the

...

default

...

values

...

of

...

the

...

substitution

...

variables.

...

These

...

are

...

copied

...

into

...

the config-substitutions.properties file;

...

you

...

are

...

expected

...

to

...

modify

...

these

...

by

...

hand

...

as

...

necessary.

...

...

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

...

e.g

...

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>

...

...

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, config-substitutions.properties and artifact_aliases.properties.

...

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

...

artifact_aliases.properties

...

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:

...

...

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.

...

Using maven to generate the Geronimo plugin descriptor

A lot of the information in geronimo-plugin.xml

...

file is

...

normally

...

known

...

to

...

maven,

...

such

...

as

...

the

...

module

...

Id

...

and

...

dependencies.

...

Thus

...

the

...

car-maven-plugin,

...

along

...

with

...

generating

...

the

...

car

...

file,

...

generates

...

geronimo-plugin.xml.

...

Much

...

of

...

the

...

content

...

is

...

simply

...

copied,

...

but

...

there

...

are

...

a

...

few

...

additional

...

configuration

...

choices.

...

Lets

...

look

...

at

...

the

...

jetty

...

web

...

container

...

plugin

...

pom.xml

...

file.

The

...

moduleId,

...

name,

...

and

...

description

...

go

...

into

...

the

...

geronimo-plugin.xml.

...

For most plugins, all the dependencies that are plugins should be running. In this case we can use the maven dependencies unmodified as the Geronimo dependencies. For some plugins, typically deployers, some of the dependent plugins need to be loaded so their classes are available but they may not need to be started (for instance they might open ports that would conflict). In such cases you need to indicate not to use the maven dependencies and to specify them explicitly in this section. The dependencies here go both into the plan.xml file and the geronimo-plugin.xml file.

...

The contents of the instance are copied pretty much unchanged into geronimo-plugin.xml. You can specify a default-instance element in a parent pom plugin configuration and that will be merged into the geronimo-plugin.xml of all the children. Note that due to some peculiarities of maven xml processing you have to use #{foo} instead of ${foo} for substitution variables.

...