Re: [Springframework-developer] Scheduler update #2

[Ivan R. <iv...@we...>]

Trevor Cook wrote:

> Ivan, while you're working on the unit tests, would it be possible to post
> your current source (probably just as a zip in this thread) for comparing
> with how to reconcile it with Quartz.

   Sure. I don't have it with me at the moment. I'll send it later,
   when I get home.


> COMPARISON
> ----------
> Chronos is create explicitly as a cron scheduler.
> Quartz is created as a "generic" scheduler, using different trigger types to
> control scheduling type (SimpleTrigger vs CronTrigger).

   Chronos works like Quartz here. The only difference is that each
   scheduler supports a utility method to convert a textual
   representation of a schedule ("*/2 * * * *") into an instance of
   a class implementing Schedule.

   Internally, scheduler uses instances of Schedule (which is basically
   a trigger in the Quartz naming scheme). Any Schedule implementation
   can be used with any Scheduler implementation.


> Chronos allows a single parameter to be added to the job during creation,
> and does not appear to have a method of passing additional information when
> the task is actually run.

   When used with a wrapper Chronos calls methods, and you can send as
   many parameters as needed.



> RECOMMENDATION
> --------------
> 1. The scheduler's persistence mechanism should be part of the scheduler
> configuration rather than as seperate methods (similiar to Quartz).  This
> would mean that Chronos would need to be changed to set this configuration.

   The problem here is that, for example, CronScheduler supports both
   persistent and non-persistent tasks at the same time.

   But it's easy to change CronScheduler (by adding a configuration
   option) to treat all tasks as persistent.

   We can't support both methods at the same time with Quartz, can we?


> 2. The scheduling mechansim should use a task/trigger mechansim (similiar to
> Quartz).  Chronos could still provide a single type of trigger (Cron), but
> this would change the scheduling mechanism.

   OK (already there, as above).


> 3. No special interface should be required thus allowing any POJO to
> function as a job (similiar to Chronos).  I'm also thinking that Spring's
> bean handling could be used to mask any parameters passed to the job so that
> a map could be converted to actual objects (especially for Quartz where
> you're bascially doing "(cast)map.get(x)" for all parameters).

   Yes.


> 4. Naming of jobs should be allowed but not required (allowing "simple"
> usage").

   Agreed. Would Quartz wrapper autogenerate names then?

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]