Code Mostly Present, Text Not Yet Finished
Here's a sample plugin setup demonstrating several advanced features. It is based on the Quartz scheduler. The plugin is separated into 3 components:
- The Quartz scheduler integration
- Deployment integration so you can deploy a JAR with Quartz job classes and execution schedules, and start and stop jobs with the Geronimo deployment tools
- Console integration so you can use a Quartz management screen in the console to edit, schedule, run, pause, and resume Quartz jobs.
Note that once the Quartz plugin is deployed, any J2EE application can get a JNDI reference to the Quartz scheduler, making it easy for applications to work with.
Before you try this process, you should be familiar with basic GBeans. There's a much more straightforward Quartz article available at http://www-128.ibm.com/developerworks/opensource/library/os-ag-thirdparty/ if you need some background (though that covers Geronimo 1.0 syntax for the XML files, which is slightly different).
For more on Quartz, see
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:
- Create a scheduler GBean (and managment interface)
- Create a job GBean (and management interface)
- Create some glue between a Geronimo thread pool and a Quartz thread pool
- Create a Geronimo deployment plan for the Quartz integration module
- 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:
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
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:
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
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:
Quartz Console Plugin Metadata
TODO: need to write this