Menu
▾
▴
springframework-developer
|
From: Kopylenko, D. <dko...@ac...> - 2003-10-09 22:36:15
|
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 ? Regards, Dmitriy. -----Original Message----- From: Ivan Ristic To: spr...@li... Sent: 10/9/2003 4:39 PM Subject: [Springframework-developer] Scheduler update After spending some time trying to create a light interface to Quartz I gave up and wrote a new scheduler package, as I had originally planned. That was several weeks ago. The project I am working on at the moment finishes in two weeks, and I expect to finish this package immediately after that. I would appreciate if anyone would care to look and comment: http://www.ivanristic.com/chronos/ It is very light and supports most of the requirements I sent in an email earlier. It contains two scheduler implementations: DefaultScheduler - non-persistent tasks executed at a regular rate (+ start date, end date, repeat count) CronScheduler - persistent cronlike tasks (but since it inherits from the DefaultScheduler it supports non-persistent tasks too). Schedulers accept Runnable instances and execute them. Wrappers are used to achieve other execution methods such as object method call, class method call, Spring event fired, Spring bean method call, etc. A typical usage would look like this: CronScheduler scheduler = new CronScheduler(); scheduler.start(); scheduler.createTask("*/2 * * * * bsh.Interpreter.source test.bsh"); Schedule schedule = new RecurringSchedule(); schedule.setRate(10000); schedule.setRepeatCount(7); scheduler.createTask(new SomeJob(), schedule); Comments related to Spring integration are especially welcome. I've done most of the work. What remains to be done is: final debugging, tests, and implementation of several helper classes in a subpackage to use other means of execution (native, HTTP, probably only ones that can be done without introducing library dependencies). I am also considering creating a MBean (more likely as my app will be JMX based) and an EJB interface (less likely). -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ] ------------------------------------------------------- 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 |
|
From: Kopylenko, D. <dko...@ac...> - 2003-10-10 01:57:34
|
> 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
|
|
From: Rod J. <rod...@in...> - 2003-10-10 07:38:22
|
Or implement BeanFactoryAware, so it could work in a BeanFactory, not just
an ApplicationContext (which is a subinterface of BeanFactory).
----- Original Message -----
From: "Kopylenko, Dmitry" <dko...@su...>
To: "'Mike Cannon-Brookes '" <mi...@at...>; "'Spring Developer '"
<spr...@li...>
Sent: Friday, October 10, 2003 2:57 AM
Subject: RE: [Springframework-developer] Scheduler update
> > 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
>
>
> -------------------------------------------------------
> 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
>
|
|
From: Ivan R. <iv...@we...> - 2003-10-09 23:25:30
|
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"
--
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]
|
|
From: Mike Cannon-B. <mi...@at...> - 2003-10-10 00:00:07
|
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"
|
|
From: Ivan R. <iv...@we...> - 2003-10-10 09:20:53
|
Mike Cannon-Brookes wrote: > Personally I'd like to see (or would be happy to create) a Quartz bean. And I would be happy to work with you so that schedulers coexist :) > 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. I am sure it seems that way from your point of view. It is different from my point of view: it doesn't give me what I want, it forces me to think about things I don't care and it simply doesn't "feel" right. For the record, after getting suggestions from this list, I did attempt to wrap Quartz and use it from Spring. For a while I thought I'll do that but I gave up after learning more about it. In the end, I do believe that it is an overkill for most uses. It is an eternal question you are asking, to "buy or build". I am not against "buying" - I happily chose to use Spring over my own XML-based configuration mechanism because I believed it is better than anything I would be able to build. I don't think that way about Quartz. > 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. Both approaches have their merits. People will probably chose on or the other depending on the type of project they have. -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ] |
|
From: Ivan R. <iv...@we...> - 2003-10-10 21:34:42
|
> 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 ?
I've made some changes, introducing the SpringBeanTask class for use
in the configuration file. Here is how you would use it:
-------------
<!-- the bean to be called at a schedule -->
<bean id="job1" class="SomeJob"/>
<!-- the scheduler instance -->
<bean id="scheduler" class="com.webkreator.chronos.CronScheduler"
init-method="start" />
<!-- task #1, bean method call with arguments on the command line -->
<bean id="job1task1" class="com.webkreator.chronos.SpringBeanTask">
<property name="bean"><value>
job1.test "testing 123"
</value></property>
<property name="schedule"><value>*/1</value></property>
<property name="scheduler"><ref bean="scheduler"/></property>
</bean>
<!-- task #2, method call with multiple arguments -->
<bean id="job1task2" class="com.webkreator.chronos.SpringBeanTask">
<property name="bean"><value>job1.test</value></property>
<property name="schedule"><value>*/1</value></property>
<property name="scheduler"><ref bean="scheduler"/></property>
<property name="arguments">
<list>
<value>arg1</value>
<value>arg2</value>
</list>
</property>
</bean>
-------------
I have also removed SpringExecWrapper since I haven't found it useful
at all (ExecWrapper works just as well) but left a part of its
functionality in the SpringEventWrapper (publishes events to
the application context at a given schedule).
The only thing that bothers me is the schedule resolution. Cron works
with minutes but that may be too long for some uses. Should seconds
and milliseconds be supported?
--
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]
|
