Call us: +1-415-738-4000
This is the most significant revision of Quartz Enterprise Job Scheduler since the project began over a decade ago.
Efforts have been made to strike a balance between preserving backward compatibility (or at least providing a fairly easy migration) and providing meaningful long-wanted changes to the API.
The most obvious differences with version 2.0 are the significant changes to the API. These changes have aimed to:
modernize the API to use collections and generics, remove ambiguities and redundancies, hide/remove methods that should not be public to client code, improve separation of concerns, and introduce a Domain Specific Language (DSL) for working with the core entities (jobs and triggers).
While the API changes are significant, and the usage of the "new way of doing things" is highly encouraged, there are
some formulaic (search-and-replace) techniques that can be used to get 1.x code quickly working with version 2.0.
See the migration guide for more information.
Outline of most significant API changes:
JobDetail job = newJob(SimpleJob.class) .withIdentity("job1", "group1") .build(); Trigger trigger = newTrigger() .withIdentity("trigger1", "group1") .startAt(futureDate(2, IntervalUnit.HOURS)) .withSchedule(repeatHourlyForever()) .modifiedByCalendar("holidays") .build();
// build a date for 9:00 am on Halloween Date runDate = dateOf(0, 0, 9, 31, 10); // build a date 2 hours in the future Date myDate = futureDate(2, IntervalUnit.HOURS);
The StatefulJob interface has been deprecated in favor of new class-level annotations for Job classes (using both annotations produces equivalent to that of the old StatefulJob interface):
New annotation: @ExecuteInJTATransaction. Adding this annotation to a Job class instructs Quartz to start a JTA transaction before executing the job (and commit/rollback after completion/exception). The configuration property 'wrapJobExecutionInUserTransaction' from version 1.x still exists, but the new annotation lets you tune the behavior on per job, while the config property affects all jobs.
Significant changes to usage of JobListener and TriggerListener:
The SchedulerException class and class hierarchy has been cleaned up.
Terracotta Quartz Scheduler Where is an Enterprise feature that allows jobs and triggers to run on specified Terracotta clients instead of randomly chosen ones. Quartz Scheduler Where provides a locality API that has a more readable fluent interface for creating and scheduling jobs and triggers. This locality API, together with configuration, can be used to route jobs to nodes based on defined criteria:
Scheduler.clear() method provides convenient (and dangerous!) way to remove all jobs, triggers and calendars from the scheduler.
XML files containing scheduling data now have a way to specify trigger start times as offsets into the future from the time the file is processed (useful for triggers that need to begin firing some time after the application is launched/deployed).
XML file schema now supports specifying the 'priority' property of triggers.
Various performance improvements, including (but not limited to):
Various bug fixes, for complete listing see the release notes from Jira: https://jira.terracotta.org/jira/secure/ReleaseNote.jspa?projectId=10282&version=10842