...

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

...

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.

...

...

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:

...

...

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:

...

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.

...

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

...

The plan is:

...

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).

...

This ends up going into a WAR like this:

...

...

Quartz Console Plugin Metadata

TODO: need to write this

...

...

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