Giacomo Pati wrote: > 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). > Yepp.
> > 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). > I know :) > > 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. > Go ahead. Carsten
