RE: [Springframework-developer] Scheduler update

[Kopylenko, D. <dko...@ac...>]

> 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.

A bean just needs to implement the ApplicationContextAware interface.

Dmitriy. 

-----Original Message-----
From: Mike Cannon-Brookes
To: Spring Developer
Sent: 10/9/2003 7:58 PM
Subject: Re: [Springframework-developer] Scheduler update

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"



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer