Seam Cron: Scheduling Portable Extension for CDI

Update: This has now made its way into Seam 3 proper, as Seam Cron. Unfortunately it won’t be available for the initial Seam 3.0 release, but will become available soonishly.

Introducing Web Beans Scheduling (now Weld Scheduling (Now Seam Cron)) – a way to run scheduled events in JBoss Weld, Seam 3 and possibly any JSR-299 implementation. It makes use of CDI’s typesafe event model for tying business logic to schedules. That is, you define your schedules using the provided qualifiers, which you apply to observer methods containing the business logic that you wish to be run at those times. In other words:

    public void onSchedule(@Observes @Scheduled("20 */2 * ? * *") CronEvent e) {
        // do something every 2 minutes, at 20 seconds past the minute.
    }

The CDI container will fire the @Scheduled(“20 */2 * ? * *”) CronEvent at 20 seconds past every second minute, causing the onSchedule method to be executed each time. When CDI starts up with this module on the classpath, all observers of the CronEvent class are detected by the module using standard CDI APIs. The module then inspects each associated @Scheduled binding annotation and sets up a schedule to fire a CronEvent with that binding at the schedule found. Currently Quartz is used as the underlying scheduler.

One obvious shortcoming of this is that we’ve managed to hard-code scheduling information in our Java code. The answer to this is to define the schedule as a property in the scheduler.properties file at the root of your classpath, for example:

# This schedule is named "test.one" and runs every 2 minutes
test.one=20 */2 * ? * *
# This schedule is named "after.hours" and runs in the wee hours every day
after.hours=0 0 2 ? * *

You can then observe that schedule like this:

    public void onNamedSchedule(@Observes @Scheduled("test.one") CronEvent event) {
        // the schedule is defined in scheduler.properties
    }

This is getting better, but that “test.one” String is still setting off some refactoring alarm bells. No worries, we can deal with this pretty easily using meta-annotations. We just create a custom qualifier like so:

@Scheduled("after.hours")
@Qualifier
@Retention(RetentionPolicy.RUNTIME)
@Target( { ElementType.PARAMETER, ElementType.METHOD, ElementType.FIELD, ElementType.TYPE })
public @interface AfterHours {}

And now we can observe the event in a typesafe manner, in as many places as we want throughout our codebase with all the benefits of code-completion and none of the refactoring headaches:

    public void onTypesafeSchedule(@Observes @AfterHours CronEvent e) {
        // do something after hours
    }

There are also some built-in convenience events for regular schedules:

    public void everySecond(@Observes @Every Second second) {
        // this gets executed every second
    }

    public void everyMinute(@Observes @Every Minute minute) {
        // this gets executed every minute
    }

    public void everyHour(@Observes @Every Hour hour) {
        // this gets executed every hour
    }

Note though that none of these built-in events will be scheduled, let alone fired, unless the module finds an observer for them on startup.

This project has been submitted to the Seam 3 sandbox (find it in seam/sandbox/modules). An early release of the Weld Scheduling module and Memory Grapher example app can be downloaded from here: WeldScheduling.tgz. They’re both built with Maven 2.0.10+. To run the example app, ‘mvn clean install‘ both projects (‘scheduling’ first, then ‘MemoryGrapher’) and then run ‘mvn -Drun install’ from inside MemoryGrapher. It uses the Weld SE extension to run it without an app server (it’s a Swing app).

8 Comments

  1. Pingback: Screaming Coder » Scheduling in Web Beans and JSR-299 Apps BEC Development Blog

  2. I love this notation — combining the scheduling with CDI’s event system, but it seems that what I see here is driven from a static schedule — ‘every hour’, ‘after hours’, or something based on cron… do you plan to provide a way to schedule something dynamically? In other words, ‘a user just took some action, let’s schedule something to fire 20 minutes from now’?

    Also, I’m a big believer in being able to configure your application from outside of a packaged .war or .ear file — any plans to support this capability?

    M

  3. Yes it’s all sourced from static configuration at the moment. But since the Environment Configuration module exports config data to JNDI, I guess it would be trivial for Scheduling to support it by simply checking for named schedules in JNDI first and then falling through to scheduling.properties. Or perhaps also checking for an entry which points to a scheduling.properties file arbitrarily located on the filesystem.

    WRT delayed execution, the API could look like this:

    @Delayed(minutes=20)
    public void doThisLater(User user) { ... }

    or like this:

    public void doThisLater(@Observes @Delayed(minutes=20) AppEvent event) { ... }

    … but I’m not sure how I’d go about implementing that yet. Also I’ll have to check out asynchronous events in the spec for any possible overlap.

  4. Nice work! Will this ever make it into any official package? Is there a maven repo for this or would you consider pushing it out to the central maven repo?

  5. Well the plan is to have this included in one of the first point releases of Seam (eg: Seam 3.0.1). In the meantime you should be able to check it out from https://github.com/seam/cron, “mvn install” and include it in your pom.xml.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>