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
