|Home > Documentation > 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:
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
The goal of the basic Quartz integration is to:
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:
Here's a sample Scheduler GBean:
Here are some things to note:
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.
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:
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.
TODO: need to write this
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.)
The deployer has a couple main responsibilites:
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.
This can be packaged into a JAR with the deployer code like this:
The plan is:
TODO: need to write this
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:
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).
This ends up going into a WAR like this:
TODO: need to write this
<------------ FALTA TRADUCCION