cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <giac...@apache.org>
Subject RE: Implementation of the Continuations checker
Date Fri, 29 Oct 2004 22:20:00 GMT
On Fri, 29 Oct 2004, Carsten Ziegeler wrote:

> Giacomo Pati wrote:
>> So, the question remains. Either we
>>
>>    integrate & refactor the excalibur event package
>>
>> or
>>
>>    make the Quartz/Cron block core as it does all we need
>>
> Yepp, I think we should use a compromise here: let's take the
> fastes road and add quartz to the core. The implementation is
> hidden behind interfaces, so if in the future we come to the
> conclusion that this dependency is not good for us, we can
> just write our own implementation while preserving the interfaces.

And eliminating ALL spawing of new Threads in the code will eventually 
allow us to be more J2EE spec conformant (I do know of prominent J2EE app 
servers Cocoon isn't able to run in just because of spawning own sub 
threads).

> I think this is on of our core problems: we not only rely on external
> implementations but also on external interfaces. Changing implementations
> is easy, changing interfaces not.

Yes, the JobScheduler is IIRC totally hidden behind our own interfaces 
(I'm the one who initially wrote it).

> So, let's use quartz, but add a good interface above it (perhaps the
> one from the cron block or a simpler one - i don't know); then refactor
> our code to use this interface.

I'd propose to move the hole block as it is alreaday shielded behind our 
own interfaces. IMHO it doesn't make much sense to have two scheduling 
mechanisms availablebased on the same external dependency.

-- 
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com

Mime
View raw message