Menu
▾
▴
springframework-developer
|
From: Ivan R. <iv...@we...> - 2003-11-02 17:34:48
Attachments:
chronos-manual.pdf
|
I've attached a rough user manual for the scheduler I have been working on, and I have allocated certain amount of time to finish it. The manual should should give you an idea of how will the schedule be used. Any comments before I go and finish this? Also: Will the scheduler be accepted as a part of Spring? I am all for having pluggable scheduler, so people can choose the one they like. Is anyone willing to contribute a Quartz wrapper? Now would be a very good time to get the abstraction interfaces right. -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ] |
|
From: Rod J. <rod...@in...> - 2003-11-03 09:09:14
|
Ivan, Thanks for the update. > Will the scheduler be accepted as a part of Spring? We should probably take a vote on this. I would probably make it a separate project and download within Spring, spring-scheduler, dependent on the main codebase. Other crucial things are: - Code review. - Volume of code. If there's lots of code, it's a stronger argument for putting it outside the main codebase. - Any dependencies it introduces. - Unit test coverage. As our target is to go above 80% for 1.0 RC1, new code must have this kind of level of test coverage, verified via Clover. - Your commitment to maintaining it, providing forum/list support etc. > I am all for having pluggable scheduler, so people can choose the one > they like. Is anyone willing to contribute a Quartz wrapper? Now would > be a very good time to get the abstraction interfaces right. +1 I think abstraction interfaces are very important, and consistent with Spring's approach in general. Providing a default scheduler implementation as standard might flow from that. Regards, Rod |
|
From: Ivan R. <iv...@we...> - 2003-11-03 10:15:59
|
> I would probably make it a separate project and download within Spring, > spring-scheduler, dependent on the main codebase. Why not in the main project? Having that functionality out of the box is very convenient. > - Volume of code. If there's lots of code, it's a stronger argument for > putting it outside the main codebase. It's actually rather small in size. Compiled classes are around 30K at the moment. > - Any dependencies it introduces. None (not counting commons-logging). > - Unit test coverage. As our target is to go above 80% for 1.0 RC1, new code > must have this kind of level of test coverage, verified via Clover. I'll look into that, add tests to the scheduler and come back later. > - Your commitment to maintaining it, providing forum/list support etc. No problem. But I do plan *not* to expand its functionality significantly. It exists only to be lightweight, and those who need more should look at more capable projects (eg Quartz). -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ] |
|
From: Rod J. <rod...@in...> - 2003-11-03 11:20:24
|
Ivan, The fact that it has a clear scope and is intended to be lightweight makes it a good candidate to be the "out-of-the-box" implementation of any Spring scheduler interface. I don't think Spring should attempt to include a full-featured scheduler. However, there is an argument for including a convenient, readily available, implementation of a scheduler abstraction. This gives the user the benefits of pluggability in good Spring fashion. Regards, Rod ----- Original Message ----- From: "Ivan Ristic" <iv...@we...> To: <spr...@li...> Sent: Monday, November 03, 2003 10:15 AM Subject: Re: [Springframework-developer] Scheduler update #2 > > > I would probably make it a separate project and download within Spring, > > spring-scheduler, dependent on the main codebase. > > Why not in the main project? Having that functionality out of the > box is very convenient. > > > > - Volume of code. If there's lots of code, it's a stronger argument for > > putting it outside the main codebase. > > It's actually rather small in size. Compiled classes are around > 30K at the moment. > > > > - Any dependencies it introduces. > > None (not counting commons-logging). > > > > - Unit test coverage. As our target is to go above 80% for 1.0 RC1, new code > > must have this kind of level of test coverage, verified via Clover. > > I'll look into that, add tests to the scheduler and come back later. > > > > - Your commitment to maintaining it, providing forum/list support etc. > > No problem. But I do plan *not* to expand its functionality > significantly. It exists only to be lightweight, and those who need > more should look at more capable projects (eg Quartz). > > -- > ModSecurity (http://www.modsecurity.org) > [ Open source IDS for Web applications ] > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: Ivan R. <iv...@we...> - 2003-11-03 11:59:22
|
> I don't think Spring should attempt to include a full-featured scheduler. I agree with that, except that I wouldn't consider this scheduler to be full-featured :) Chronos is an attempt at a small library to satisfy the needs of most people so that they don't have to go out and learn more complex libraries. If you don't think that it should be a part of Spring I have no problem with that. > However, there is an argument for including a convenient, readily available, > implementation of a scheduler abstraction. This gives the user the benefits > of pluggability in good Spring fashion. We'll see whether someone will come forward. Or, we may attempt to contact the Quartz people and seek their help/opinion. -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ] |
|
From: Cameron B. <ca...@da...> - 2003-11-03 12:04:47
|
At first I was thinking that the better approach was to include an 'out-of-the-box' plugin for quartz, since it is a system that I have used before. though after reading the Chronos manual, I think that something really simple like that may be a very good idea. I would still like to see spring provide support for Quartz :) Cameron. Ivan Ristic wrote: > >> I don't think Spring should attempt to include a full-featured >> scheduler. > > > I agree with that, except that I wouldn't consider this scheduler to > be full-featured :) Chronos is an attempt at a small library to > satisfy the needs of most people so that they don't have to go out > and learn more complex libraries. > > If you don't think that it should be a part of Spring I have no > problem with that. > > >> However, there is an argument for including a convenient, readily >> available, >> implementation of a scheduler abstraction. This gives the user the >> benefits >> of pluggability in good Spring fashion. > > > We'll see whether someone will come forward. Or, we may attempt to > contact the Quartz people and seek their help/opinion. > -- Any damn fool can write code that a computer can understand... The trick is to write code that humans can understand. [Martin Fowler http://www.martinfowler.com/distributedComputing/refactoring.pdf] |
|
From: Rod J. <rod...@in...> - 2003-11-03 12:22:01
|
Ivan, I meant that Chronos was small, not a "full-featured scheduler", and that is good. Therefore it could potentially be part of Spring. Regards, Rod ----- Original Message ----- From: "Ivan Ristic" <iv...@we...> To: <spr...@li...> Sent: Monday, November 03, 2003 11:59 AM Subject: Re: [Springframework-developer] Scheduler update #2 > > > I don't think Spring should attempt to include a full-featured scheduler. > > I agree with that, except that I wouldn't consider this scheduler to > be full-featured :) Chronos is an attempt at a small library to > satisfy the needs of most people so that they don't have to go out > and learn more complex libraries. > > If you don't think that it should be a part of Spring I have no > problem with that. > > > > However, there is an argument for including a convenient, readily available, > > implementation of a scheduler abstraction. This gives the user the benefits > > of pluggability in good Spring fashion. > > We'll see whether someone will come forward. Or, we may attempt to > contact the Quartz people and seek their help/opinion. > > -- > ModSecurity (http://www.modsecurity.org) > [ Open source IDS for Web applications ] > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: Ivan R. <iv...@we...> - 2003-11-03 12:40:08
|
Rod Johnson wrote: > I meant that Chronos was small, not a "full-featured scheduler", and that is > good. Therefore it could potentially be part of Spring. Oh, right. Sorry about that, I'll try to pay more attention to what you're actually saying :) I'll work to finish it by the end of the week and then we'll see how it fares. But I too wouldn't include it without a Quartz support. -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ] |
|
From: Trevor C. <pr...@se...> - 2003-11-03 14:04:44
|
Thanks Ivan. I've taken a quick look at the manual, and it looks pretty
good. I think Rod covered all the things necessary for Spring, so assuming
those are met, I'd vote to have the simple scheduler (yours) inside Spring
("out-of-the-box"), with a Quartz wrapper available.
I'll dig a little deeper today and compare it to what might be needed for
Quartz (since that's what I use, and what everyone seems to be asking for).
However, a really light-weight option like yours is definately good for
Spring.
Trevor
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Ivan Ristic
Sent: November 3, 2003 6:59 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Scheduler update #2
> I don't think Spring should attempt to include a full-featured scheduler.
I agree with that, except that I wouldn't consider this scheduler to
be full-featured :) Chronos is an attempt at a small library to
satisfy the needs of most people so that they don't have to go out
and learn more complex libraries.
If you don't think that it should be a part of Spring I have no
problem with that.
> However, there is an argument for including a convenient, readily
available,
> implementation of a scheduler abstraction. This gives the user the
benefits
> of pluggability in good Spring fashion.
We'll see whether someone will come forward. Or, we may attempt to
contact the Quartz people and seek their help/opinion.
--
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: Trevor C. <pr...@se...> - 2003-11-03 17:02:53
|
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. My early findings are based on assumptions I'm making about "Chronos". If any of my assumptions are incorrect, please let me know (I should be more accurate once I can examine the source). 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 uses 2 different methods for creating tasks, one for "in-memory" and one for "persistent". Quartz uses a single scheduling mechanism. The underlying store (ram or jdbc) is determined by the schedulers configuration. Chronos allows any POJO to be turned into a task by wrapping it. Quartz requires objects to implement "Job" which contains a single method "execute(JobExecutionContext context)". 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. Quartz stores parameters with the Job, and also allows modifying the "JobExecutionContext" just before execution through the use of a "JobListener". Quartz uses names for the tasks (and also has groups). Chronos does not appear to have any naming for it's tasks. 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. 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. 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). 4. Naming of jobs should be allowed but not required (allowing "simple" usage"). Once I get the Chronos source-code, I'll try to make a few concrete examples. If there are no objections, I'll put the examples, initial Spring scheduling interfaces, and Chronos code into the sandbox so everyone can see it and make comments. This will also require adding Quartz to Spring, although this will only affect developer/cvs downloads (I won't be adding it to the distribution build scripts). Any objections? Trevor |
|
From: Ivan R. <iv...@we...> - 2003-11-03 17:30:15
|
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 ]
|
|
From: Trevor C. <pr...@se...> - 2003-11-03 17:44:28
|
>> 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? No, Quartz does it at configuration time. From a really high level, it's basically "2 schedulers, 1 scheduling method" vs. "1 scheduler, 2 scheduling methods". From a user view, 2 methods means choosing persistence mechanism in the use case, while 2 schedulers means the use case uses a single generic method and doesn't care about the type of scheduler (which can be configured in Spring's context). While both are effective and work, I think the latter allows more flexibility and is closer to Spring's abstraction model. >> 4. Naming of jobs should be allowed but not required (allowing "simple" >> usage"). > > Agreed. Would Quartz wrapper autogenerate names then? Quartz doesn't, but I think Spring's "quartz-wrapper" should. Complicating "Chronos" doesn't make sense, and the overloaded method which will accept a name will still allow implicit naming. Trevor -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ] ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Ivan R. <iv...@we...> - 2003-11-03 23:11:43
|
> My early findings are based on assumptions I'm making about "Chronos". If > any of my assumptions are incorrect, please let me know (I should be more > accurate once I can examine the source). Here is the Javadoc documentation: http://www.webkreator.com/download/chronos/javadoc/ and here's the source: http://www.webkreator.com/download/chronos/chronos-20031103.zip (the Eclipse folder archived) I'll probably remove the CronTask class. The PersistentScheduler interface is not used (it will probably be removed, too). Other than this I plan to change CronScheduler.createTask(String) into CronScheduler.createTask(String, String) (as in the manual). -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ] |
