On Mon, 1 Sep 2003, Bruno Dumon wrote: > On Mon, 2003-09-01 at 16:29, Giacomo Pati wrote: > > On Mon, 1 Sep 2003, Bruno Dumon wrote: > > > > > On Mon, 2003-09-01 at 11:37, Giacomo Pati wrote: > > > > On Mon, 1 Sep 2003, Reinhard Poetz wrote: > > > > > > > > > > > > > > > > > > > On Behalf Of Giacomo Pati > > > > > > > > > > > On Mon, 1 Sep 2003, Andreas Hochsteger wrote: > > > > > > > > > > > > > Hi! > > > > > > > > > > > > > > Just in case you didn't know: > > > > > > > Did you have a look at the Quartz Scheduler? > > > > > > > http://www.part.net/quartz.html > > > > > > > http://www.part.net/quartz_features.html > > > > > > > Perhaps it already does what you need. > > > > > > > It's licensed under a BSD and Apache-Style license. > > > > > > > > > > > > I've seen it some time ago but thought it is quite too much > > > > > > for a simple cron mechanism we are discussing here. > > > > > > > > > > > > Any other thoughts? > > > > > > > > > > Do you think it is difficult to use/to integrate? From the features list > > > > > it is exactly what we need, isn't it? > > > > > > > > IMHO, from the feature list it is way too much we need, isn't it? > > > > > > I think many of it are optional features, and those extra features might > > > come in handy some day. If it does everything we need and if it's solid, > > > why not use it? > > > > Hmm, the cocurrency util from Doug Lea does alot Quartz offers. > > Hmm, as far as I know, only the threadpool? (which is of course an > important part). Quartz has either a very simple thread pool of its own > or otherwise uses something from jakarta commons. I think it would be > easy to put PooledExecutor behind it.
Ok, I've rewritten the Scheduler using Quartz as scheduling engine (and using its CronTrigger class) but put an PooledExecutor underneath as the ThreadPool. > > So my > > oppinion was not to add another dependency. > > Sometimes it sounds more compelling to add another dependency maintained > by another community than to add more code to Cocoon. Ok, convinced :-) > > Quartz (if I've read the > > feature list correctly) doesn't offer Cron spec parsing, > > Hope you look a bit further than the first web page to judge a piece of > software (imagine if people would do that for cocoon...) Sorry, yes now I've seen it and it has quite more feature as my implementation. > See this: > http://quartz.sourceforge.net/javadoc/org/quartz/CronTrigger.html > > Furthermore, from having a quick look, quartz is quite modular, with > different implementations available, in its simplest form without any > third party jars requirements. Yup. I've seen. > > It also seems to be able to calculate the time to perform to the next > task to be performed. > > > so we have to > > do it anyway. And because I've alread done this for another project some > > times ago I thought to but it into a Scheduler by it own (mean in the > > org.apache.cocoon package space). > > > > So, the scheduler I've proposed is already done. I just have to > > repackage it and add some more javadocs etc. It's about to be ready to > > be committed tomorrow. > > > > If there are still objection I hold on the commits until we reached > > consensus. > > I have two more questions: > > * what do we need a scheduler for in Cocoon in the first place? > > * would your scheduler be able to handle the ContinuationsManager > cleanup task? The specific requirement I'm thinking of is that it > shouldn't be launched concurrently, so if the previous cleanup is still > running it shouldn't be launched a second time. The interface for a Scheduler so far isn't complete but, yes, The ContinuationsManager could launch it's own jobs as the Scheduler is implemented as a regular Avalon component. I've also implemented configurable en-/disable parallel runs. > > Other than that, I'll leave it up to your good judgement on what path to > follow, I don't have any experience with any schedulers anyway... > > -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com
