geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <ammul...@alumni.princeton.edu>
Subject Re: Adding new deployable module types
Date Sat, 10 Jun 2006 22:59:43 GMT
On 6/10/06, Stefan Arentz <stefan.arentz@gmail.com> wrote:
> First question: What is it that connects a Quartz Job Deployment Plan
> to the Quartz Job Deployer? Is it simply the xml schema namespace
> defined in geronimo-quartz-0.1.xsd?

Right -- the schema, and the fact that the plan was in the right place
for us to find to being 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.  For example:

            XmlObject xmlObject;
            if (planFile != null) {
                xmlObject = XmlBeansUtil.parse(planFile.toURL());
            } else {
                URL path = DeploymentUtil.createJarURL(jarFile,
"META-INF/geronimo-quartz.xml");
                try {
                    xmlObject = XmlBeansUtil.parse(path);
                } catch (FileNotFoundException e) {
                    // It has a JAR but no plan, and nothing at
META-INF/geronimo-quartz.xml,
                    // therefore it's not a quartz job deployment
                    return null;
                }
            }
            if (xmlObject == null) {
                return null;
            }

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

            XmlCursor cursor = xmlObject.newCursor();
            try {
                cursor.toFirstChild();
                if (!SERVICE_QNAME.equals(cursor.getName())) {
                    return null;
                }
            } finally {
                cursor.dispose();
            }

The (badly named) constant SERVICE_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.

So far so good?

Thanks,
    Aaron

Mime
View raw message