Using the embedded scheduler, you can write a standard Quartz job like this. Note that the job must create its own connection to the database and its own JavaMail session.

Job Code

public class FileDBJob implements Job {
    public void execute(JobExecutionContext context)
                             throws JobExecutionException {
        // Locate input
        File source = new File(...);
        if(!source.exists()) {
            return;
        }

        // Write to database
        Connection con = DriverManager.getConnection("url",
                                       "user", "password");
        PreparedStatement ps = con.prepareStatement(...);
        ...
        con.close();

        // Send e-mail
        Properties props = new Properties();
        props.put("mail.smtp.host", smtpServer);
        ...
        Session session = Session.getDefaultInstance(props, null);
        Message msg = new MimeMessage(session);
        ...
        Transport.send(msg);
    }
}

To deploy the job, you need to:

The code to do the last two steps looks like this. It could be executed in a startup servlet, or on demand by a web or EJB component, etc.

Component that Schedules a Job

Context ctx = new InitialContext();
QuartzScheduler gbean = ctx.lookup("java:comp/env/Scheduler");
Scheduler scheduler = gbean.getNativeScheduler();
JobDetail detail = new JobDetail("name", "group", MyJob.class); 
Trigger trigger = ...; // set the schedule for the job
scheduler.scheduleJob(detail, trigger);

In order for the JNDI lookup to access the scheduler GBean, the component should include a gbean-ref element in its deployment plan (e.g. geronimo-web.xml or openejb-jar.xml):

GBean Reference in Geronimo Plan

<gbean-ref>
  <ref-name>Scheduler</ref-name>
  <ref-type>org.gplugins.quartz.QuartzScheduler</ref-type>
  <pattern>
    <name>QuartzScheduler</name>
  </pattern>
</gbean-ref>

Note that the ref-name defines the JNDI location where the QuartzScheduler GBean will be bound (java:comp/env/ plus the ref-name value -- or java:comp/env/Scheduler in this case, which is where the sample code above looks it up).

With the deployable jobs approach, the sample job can be packaged in a JAR on its own, with its classes and schedule, and can be configured to access a database pool and mail session already deployed in Geronimo (rather than manually configuring connectivity in the job). The same job would look like this:

Job Code

public class FileDBJob implements Job {
    private DataSource dataSource;
    private Session mailSession;

    public void setDatabase(DataSource ds) {
        dataSource = ds;
    }

    public void setMailSession(Session s) {
        mailSession = s;
    }

    public void execute(JobExecutionContext context)
                             throws JobExecutionException {
        // Locate input
        File source = new File(...);
        if(!source.exists()) {
            return;
        }

        // Write to database
        Connection con = dataSource.getConnection();
        ...
        con.close();

        // Send e-mail
        Message msg = new MimeMessage(mailSession);
        ...
        Transport.send(msg);
    }
}

Notice that something must call setDatabase and setMailSession on the job before it can be executed. We'll configure the job to use a particular database pool and mail session already configured in Geronimo, and the plugin will ensure that those properties are injected into the job before running the job. The job code itself doesn't need any particular settings (database connection settings or mail server settings), which means not only are those settings more secure, but also the job won't need to change as frequently and will be more portable across different server instances.

To configure the job schedule and resources, an XML deployment plan must be included with the JAR containing the job classes. It can be packaged into the JAR at the location META-INF/geronimo-quartz.xml, or provided as a separate argument in addition to the JAR when deploying the job.

geronimo-quartz.xml

<?xml version="1.0" encoding="UTF-8"?>

<jobs xmlns="http://geronimo.apache.org/xml/ns/plugins/quartz-0.2">
    <environment xmlns="http://geronimo.apache.org/xml/ns/deployment-1.1">
        <moduleId>
            <artifactId>FileDBJob</artifactId>
        </moduleId>
        <dependencies>
            <dependency>
                 <groupId>example</groupId>
                 <artifactId>javamail-server</artifactId>
            </dependency>
            <dependency>
                 <groupId>geronimo</groupId>
                 <artifactId>system-database</artifactId>
             </dependency>
        </dependencies>
    </environment>
    <job>
        <job-name>Load File into Database</job-name>
        <job-class>com.example.FileDBJob</job-class>
        <cron-expression>0 0 23 * * ?</cron-expression>
        <resource-ref>
            <property>Database</property>
            <res-type>javax.sql.DataSource</res-type>
            <res-auth>Container</res-auth>
            <res-sharing-scope>Shareable</res-sharing-scope>
            <pattern>
                <name>SystemDatasource</name>
            </pattern>
        </resource-ref>
        <resource-ref>
            <property>MailSession</property>
            <res-type>javax.mail.Session</res-type>
            <res-auth>Container</res-auth>
            <res-sharing-scope>Shareable</res-sharing-scope>
            <pattern>
                <name>MailServer</name>
            </pattern>
        </resource-ref>
    </job>
</jobs>

This looks similar to other Geronimo deployment plans, except the meaty part defines Quartz jobs instead of servlets or EJBs. Some important parts to note include:

If both the job class and deployment plan are packaged into a JAR, the JAR contents might look like this:

> jar -tf file-db-job.jar
META-INF/
META-INF/MANIFEST.MF
META-INF/geronimo-quartz.xml
com/
com/example/
com/example/FileDBJob.class

The Quartz console walkthrough will be added when the Quartz console plugin is released.