Re: [Springframework-developer] Scheduler update

[Mike Cannon-B. <mi...@at...>]

Personally I'd like to see (or would be happy to create) a Quartz bean.
Rewriting your own scheduler seems like a waste of effort to me? Quartz is
extremely flexible, Open Source and has been debugged for a long time!
Writing a scheduler is no easy task.

We have a simple XML format in house for configuring Quartz with volatile
jobs and triggers, and which currently uses a ServletListener to start it.

On a side note - is there a way for a bean to receive a reference to it's
context? This would be useful for a scheduler as it could then pas that
context on to each of the jobs it has configured.

Why not configure them all in the context file? Simply put there are often
hundreds of scheduled jobs and they more belong in their own custom file
IMHO.

M

On 10/10/03 9:26 AM, "Ivan Ristic" (iv...@we...) penned the words:

> Kopylenko, Dmitry wrote:
>> Ivan,
>> 
>> would it make sense to make SpringExecWrapper a bean, that is, expose its
>> properties (i.e bean, event, methodName, args) so they could be configured
>> through an application context and also make it implement
>> ApplicationContextAware interface, so the ApplicationContext would be
>> provided to it by the BeanFactory ?
> 
>  Interesting idea. I always thought about creating a class such as
>  SpringAwareCronScheduler and then configuring it via parameters.
> 
>  Your approach may be better, but I'd rather create a new class
>  for that then use the wrapper itself.
> 
>  How would this class know which scheduler to use? Look it up by
>  name ('scheduler') or have a setter method accepting a scheduler
>  instance? I would go with the setter method: you first create your
>  beans, then the schedule, and then create as many tasks as needed.
> 
>  Besides, it would also work with the auto-wire feature ;)
> 
>  BTW, the biggest problem I had when I was trying to create an
>  interface for various scheduling implementations was the way
>  schedules are specified. At best we will have to accept that
>  a schedule is specified with a single string.
> 
>  I could refactor RecurringSchedule to accept something like
>  this on input:
> 
>  "rate=5000ms, repeatCount=10"