Need support for Quartz 2.0 [SPR-8359]

[spring-projects-issues]

Rafal Jaworski opened SPR-8359 and commented

Could not start any scheduled task when using SchedulerFactoryBean with Quartz 2.0. (with 1.8.5 everything works fine). The reason is new JobFactory interface in Quartz - spring AdaptableJobFactory implements old version of this interface.

---

Affects: 3.0.5

Issue Links:

• Support Quartz 2.0.x [SPR-8275] #12923 Support Quartz 2.0.x
• Implement new method from ClassLoadHelper to make Spring work with Quartz 2.1 [SPR-8727] #13369 Implement new method from ClassLoadHelper to make Spring work with Quartz 2.1
• Spring should support Quartz 2.0 CronTrigger interface [SPR-8581] #13225 Spring should support Quartz 2.0 CronTrigger interface

1 votes, 5 watchers

[spring-projects-issues]

Donnchadh O Donnabhain commented

See #12923

[spring-projects-issues]

Juergen Hoeller commented

I have updated Spring's AdaptableJobFactory to be compatible with Quartz 2.0's variant of the JobFactory interface as well. This will make it into Spring Framework 3.1 M2.

However, we have not updated our Quartz scheduling package for the general JobDetail/Trigger type changes in Quartz 2.0; so Spring's JobDetailBean etc won't work with Quartz 2.0 yet.

Juergen

[spring-projects-issues]

Stéphane Nicoll commented

Is the fix 3.2 or 3.1 after all then? Right now it is 3.2 RC1

[spring-projects-issues]

Chris Beams commented

To the extent that Juergen has already addressed it, this fix version for this issue (now resolved) is 3.1 M2. For complete Quartz 2.0 support, please watch #12923, which we'll review and address in the 3.2 timeline.

[spring-projects-issues]

Sebastian Janzen commented

That change does not work for me. I'm getting a IncompatibleClassChangeError. The source is here in AdaptableJobFactory on createJobInstance:

protected Object createJobInstance(TriggerFiredBundle bundle) throws Exception {
return bundle.getJobDetail().getJobClass().newInstance();
}

Strange: In Eclipse debugger I can watch the result from newInstance(), which gives me my Object, which is a JobDetail-Class Instance, which implements the Job interface.
Exception text: Found interface org.quartz.JobDetail, but class was expected.
Calls which fires job creation:
JobDetail job = org.quartz.JobBuilder.newJob(MyJob.class). ... .build();
scheduler.scheduleJob(job, trg);
Signature of MyJob: public class MyJob implements Job {...}
Versions: Spring 3.2.M2, Quartz 2.0.2 (from Maven), Java 6, OS X

[spring-projects-issues]

Sebastian Janzen commented

I cannot modify a comment, my Spring Verion is of course 3.1.M2.

[spring-projects-issues]

Sebastian Janzen commented

Forum Thread (unresolved) for this:
http://forum.springsource.org/showthread.php?112064-3.1.M2-Quartz-2-Errors-on-new-AdaptableJobFactory-changes

[spring-projects-issues]

Juergen Hoeller commented

Good catch - the fix in 3.1 M2 was incomplete. I've fixed this for 3.1 RC1, as part of a general Quartz 2.0 update: Except for JobDetailBean and the TriggerBeans, the entire Spring Quartz support is compatible with Quartz 2.0 now (making quite heavy use of reflection internally), while at the same time remaining compatible with Quartz 1.5+.

Juergen

[spring-projects-issues]

Matt Young commented

You say, "except for JobDetailBean and TriggerBeans", how long before those have been ported? Is quartz 2.0 usable in spring 3.1 without those 2 classes being made compatible?

[spring-projects-issues]

Juergen Hoeller commented

You'll see in JobDetailBean etc's javadoc: We recommend the use of Quartz 2.0's native JobDetailImpl/CronTriggerImpl/SimpleTriggerImpl class or the new Quartz 2.0 builder API instead (the latter in particular within Spring 3.0 @Bean methods). This is in line with the way that Quartz 2.0 has been designed. Note that Quartz 2.0 breaks compatibility with quite a few of its own APIs, so don't be surprised that you'll have to adapt your code a bit.

Also, be aware that jobs and triggers can not only be defined declaratively against Spring's SchedulerFactoryBean but also programmatically against the Quartz Scheduler API itself (just do @Inject Scheduler in one of your managed beans and call the scheduleJob method there). With the latter approach, you wouldn't use JobDetailBean etc anyway; even with older Quartz versions, you would typically use native JobDetail and Trigger classes.

Spring's JobDetailBean etc were just convenience subclasses of the regular Quartz classes there. Everything configurable there can also be configured on an instance of the native Quartz 2.0 JobDetailImpl etc class, even using regular bean properties. There are just minor inconveniences such as having to refer to a job by job name and group name in the trigger definitions (instead of through a JobDetail reference). Some features such as "applicationContextJobDataKey" are outdated in the meantime, with that key rather to be set on the SchedulerFactoryBean. The only somewhat missing functionality is "startDelay" on our TriggerBeans which with standard Quartz can only be defined through a "startDate" (System.currentTimeMillis + startDelay).

If there is anything you're missing in Quartz 2.0's native JobDetailImpl/CronTriggerImpl/SimpleTriggerImpl classes, I'd recommend raising it with the Quartz team. A setStartDelay method would be trivial to add to the native Quartz trigger classes, for example. Fundamentally, there is no need for Spring to maintain its own subclasses there, and as of Quartz 2.0, there are no plans to keep doing that from our side.

Hope that helps,

Juergen

[spring-projects-issues]

sreekanth commented

Its still giving problems while using quartz-2.1.5 and i'm using Spring 3.1.0. RELEASE

[spring-projects-issues]

Chris Beams commented

sreekanth, please open a new issue and explain reproduction steps, etc if this is still an issue for you. Thanks.

[spring-projects-issues]

sreekanth commented

Thanks Chris.. will open a new issue.

[spring-projects-issues]

sreekanth commented

Sorry Chris a small question 3.1 RC1 means the fix will be available from 3.1.1 Release ?

[spring-projects-issues]

Sam Brannen commented

sreekanth,

If the fix version for an issue is 3.1 RC1, that means that the fix will be available in 3.1 RC1, any subsequent 3.1 release candidates (RC#), and 3.1 GA (i.e., the final 3.1 release).

So, yes, a fix version of 3.1 RC1 means that the fix is also available in later releases such as 3.1.1.

Regards,

Sam