HomeDocumentation > Apache Geronimo v1.1 - Guí­a de Usuario > Aplicaciones ejemplo > Ejemplo de Plugin Avanzado

La mayoría del código está presente, el texto aún no está finalizado

Se trata de una preparación ejemplo de un plugin que demuestra varias características avanzadas. Está basado en el calendarizador Quartz. El plugin se separa en 3 componentes:

  • La integración del calendarizador Quartz
  • La integración con la Activación (Deployment), tal que puedas activar un JAR con las clases Quartz de trabajo y con calendarios de ejecución, e iniciar y detener trabajos con las herramientas de activación de Geronimo.
  • La integración con Consola, tal que puedas usar una pantalla de administración Quartz en la consola para editar, calendarizar, ejecutar, pausar, y continuar trabajos Quartz.

Nota que una vez que el plugin Quartz es activado, cualquier aplicación J2EE puede obtener una referencia JNDI para el calendarizador Quartz, facilitando a las aplicaciones el poder trabajar con el.

Antes de que pruebes este proceso, deberías familiarizarte con las bases de GBeans. Existe un artículo de Quartz más concreto en http://www-128.ibm.com/developerworks/opensource/library/os-ag-thirdparty/
por si requieres una introducción (aunque en el artículo cubre la sintaxis de archivos XML en Geronimo 1.0, que es un poco diferente).

Para mayor información de Quartz, consulta

------------> FALTA TRADUCCION

Quartz Integration

The goal of the basic Quartz integration is to:

  • Wrap a Quartz scheduler in a GBean, so it's started and stopped with its Geronimo module
  • Make Quartz use a Geronimo thread pool instead of its own
  • Wrap Quartz jobs as GBeans so a job can be represented as a Geronimo component

The next sections will talk about deploying and managing Quartz jobs, and managing the Quartz scheduler and jobs through the Geronimo console.

As described here, this does not expose the full power of Quartz. This package does not let you configure database persistence, or deploy jobs on schedules other than Cron schedules, etc. This may or may not be sufficient for your needs, but it's certainly enough for this example.

The steps described here are:

  1. Create a scheduler GBean (and managment interface)
  2. Create a job GBean (and management interface)
  3. Create some glue between a Geronimo thread pool and a Quartz thread pool
  4. Create a Geronimo deployment plan for the Quartz integration module
  5. Create the plugin metadata for the Quartz plugin

Quartz Scheduler GBean

Here's a sample Scheduler GBean:

Here are some things to note:

  • The GBean has a reference to a Geronimo ThreadPool, and during doStart, it overwrites the default Quartz thread pool settings with this. The mechanism is a little weird since Quartz expects to create a new thread pool instead of accessing an existing one in the server environment, so we have to stuff the Geronimo thread pool into a map and the pass the index of the map entry to the new thread pool class that Quartz instantiates, whereupon it can look up the original pool again.
  • The GBean takes a kernel reference, which is used to look up Job GBeans on the fly (in the getJob method)
  • All the methods deal only with jobs in the "Geronimo Quartz" group – we don't try to manage other jobs that may have been deployed to Quartz without using this GBean plumbing.
  • Again, this GBean only exposes a small fraction of the methods available in the Quartz scheduler, but it's enough for our purposes

The management interface for the Scheduler GBean looks like this. This interface will be used by callers to interact with the GBean (and it's what an application will get if the app maps the QuartzScheduler into its JNDI space). While an interface isn't required, it's definitely recommended.

Quartz Job GBean

Quartz/Geronimo Thread Pool

Geronimo Deployment Plan

If you compile the previous classes and put them in a JAR, you can create the following deployment plan and either keep it outside the JAR or save it to META-INF/geronimo-service.xml in the JAR. For example, the JAR might look like this:

META-INF/
META-INF/MANIFEST.MF
META-INF/geronimo-service.xml
org/
org/gplugins/
org/gplugins/quartz/
org/gplugins/quartz/QuartzJob.class
org/gplugins/quartz/QuartzJobGBean.class
org/gplugins/quartz/QuartzScheduler.class
org/gplugins/quartz/QuartzSchedulerGBean.class
org/gplugins/quartz/QuartzThreadPool.class

The deployment plan is:

Note that in order to deploy this, you must have Quartz in your Geronimo repository (e.g. repository/opensymphony/quartz/1.5.2/quartz-1.5.2.jar). If you install the Quartz integration as a plugin, this will be installed for you automatically.

Quartz Plugin Metadata

TODO: need to write this

Quartz Deployment Integration

Quartz Job Deployment Plan Format

Sample:

We use Maven 2 and XMLBeans to code-generate classes corresponding to this Schema, using a Maven POM like this. (Note the extra dependency because the schema above imports the Geronimo schema, whose classes are in the geronimo-service-builder module.)

Quartz Job Deployer

The deployer has a couple main responsibilites:

  • Check whether this deployer can deploy the requested module
  • Confirm that the deployment plan is valid
  • Generate a Module ID for the deployment
  • Create GBeans that will be the "deployed" form of the module

Generally, this can be reduced to "input XML, output either null or Module ID plus GBeans".

Here's the deployer:

One thing to notice is how the Quartz Job Deployment Plan is connected to the Quartz Job Deployer. It is based on the schema namespace (http://geronimo.apache.org/xml/ns/plugins/quartz-0.1), and the fact that the plan was in the right place for us to find to begin with. For all the deployers we've done so far, we use XMLBeans to create JavaBeans connected to the schema. Then we use XMLBeans to read in the deployment plan, and check whether it's the type this deployer expects. Here's an excerpt from the deployer above:

This part establishes that we can load a plan at all. If not, it either means no plan was provided, or the plan is in the module at a different location (e.g. WEB-INF/geronimo-web.xml, meaning it's definitely not a Quartz job). Either way, this deployer can't handle the archive so we return null.

If we get past that, it means that we found a plan. So we go on to check the type:

The constant JOBS_QNAME is a reference to the schema namespace of the first element in the file. If it's the one we're looking for, great. Otherwise, even though we found a plan, it was not the right type of plan (e.g. someone passed a web plan on the command line), so this deployer can't handle it.

If we get past those two checks (plan present and plan has correct namespace) then we assume that it really was meant for this deployer to handle, and for other kinds of errors (syntax error in plan, etc.) we throw a deployment exception. Some of the deployers have additional logic to silently upgrade old-format plans to current-format plans, but this one does not.

Geronimo Plan for Quartz Deployer

This can be packaged into a JAR with the deployer code like this:

META-INF/
META-INF/MANIFEST.MF
META-INF/geronimo-service.xml
org/
org/gplugins/
org/gplugins/quartz/
org/gplugins/quartz/deployment/
org/gplugins/quartz/deployment/QuartzJobDeployer.class
(a bunch of XMLBeans and Maven stuff)

The plan is:

Plugin Metadata for Quartz Deployer

TODO: need to write this

Quartz Console Integration

Quartz Console Portlet

Note that this portlet can access the QuartzScheduler in JNDI at java:comp/env/Scheduler by adding the following reference to geronimo-web.xml:

That assumes that the Quartz package is listed as a dependency higher up in geronimo-web.xml:

Console Update GBean

The secret sauce here is a GBean that rewrites the console config files. After that, you just have to hit http://localhost:8080/console/portal/welcome?hotDeploy=true (note that last bit) to force the console to reread its configuration files. I'm sure there's a better way, but hey.

This GBean can be reused to install any portlets into the console (though it's configured to add one new page with any/all the portlets on that single page).

The deployment plan block that configures this GBean is added to geronimo-web.xml for the web app, and looks like this:

The "title" is the name of the entry for the new page in the console, the "webApp" is the context root of the web application containing the portlets, and the "portlets" is a list of portlets by the name they declare in portlet.xml. Note that if there were multiple portlets, the portlets property would use a comma-separated list (but there's still only one page/title and web app).

Quartz Console Packaging

This ends up going into a WAR like this:

META-INF/MANIFEST.MF
WEB-INF/
WEB-INF/web.xml
WEB-INF/portlet.xml
WEB-INF/geronimo-web.xml
WEB-INF/classes/
WEB-INF/classes/org/
WEB-INF/classes/org/gplugins/
WEB-INF/classes/org/gplugins/console/
WEB-INF/classes/org/gplugins/console/quartz/
WEB-INF/classes/org/gplugins/console/quartz/QuartzPortlet.class
WEB-INF/classes/org/gplugins/console/util/
WEB-INF/classes/org/gplugins/console/util/AddToConsoleGBean.class
WEB-INF/lib/
WEB-INF/lib/jstl-1.1.1.jar
WEB-INF/lib/standard-1.1.1.jar
WEB-INF/tld/
WEB-INF/tld/portlet.tld
(plus JSPs, images, etc.)

Quartz Console Plugin Metadata

TODO: need to write this

<------------ FALTA TRADUCCION