How to know if a specific job is running using quartz with jboss seam?

Question

I am using Jboss-seam 2.2.2.Final and I have some quartz jobs. During the application execution, I have to verify if a specific job is running.

I already have access to the jobs, but each one has a name that is created by quartz. Here is the code for the seam injection:

    @In("org.jboss.seam.async.dispatcher")
    private QuartzDispatcher quartzDispatcher;

To get the running jobs, I have this code:

    Scheduler scheduler = quartzDispatcher.getScheduler();
    List<JobExecutionContext> currentJobs;
    currentJobs = scheduler.getCurrentlyExecutingJobs();
    for (JobExecutionContext jobCtx: currentJobs){
        System.out.println(jobCtx.getJobDetail().getName());
    }

Anyone know's how to put a name on a quartz job, using jboss-seam? I have doing some research and found this ticket on jira: https://issues.jboss.org/browse/JBSEAM-4399

Answer 1

Seam generates an UUID-based unique name for each job, there's no direct way of overriding this. Your alternatives are:

1. Use the patch found, this requires building a custom Seam library with the customized code added.

2. Override the OOTB quartz dispatcher with your own custom dispatcher, override the scheduleWithQuartzService method and use your own scheme for naming the job (look at the source code for org.jboss.seam.async.QuartzDispatcher you'll see that it calls a nextUniqueName() method that generates a new unique name for the job, you need to get the job name from elsewhere, eventually in the same way it is done in the patch you found, via an annotation).

3. Instead of trying to see if the job is running based on its name, you can create a quartz event listener implementing org.quartz.JobListener and register when a job begins and ends execution in a global hashtable or something like that. Then you lookup the job in the hashtable to get its status rather than searching it by name. This however works only if your scheduler is not clustered (quartz will notify only the listener in the local node, other nodes will not know the job was triggered).