avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject Re: [Components: TimeScheduler] TimeScheduler behaviour with periodic triggers
Date Sat, 23 Aug 2003 09:47:54 GMT
Stefan Seifert wrote:
> OK, sounds reasonable. Attached is a new patch, which makes it
> possible to override the default implementation of "runEntry",
> without changing the current rescheduling behaviour.
> I'm not altogether happy with this patch because now some seemingly
> random methods and fields are protected, some are private. And
> because of dependencies of the non-public class TimeScheduleEntry the
> overriding class has to be placed in the package
> org.apache.avalon.cornerstone.blocks.scheduler as well.
> Do you want to apply this patch in this way, or should i/we
> 1) try to make a consistent "contract interface" for overiding
> selected implementation details of the DefaultTimeScheduler class,
> but perhaps some refactoring is needed to achieve that.
> or 2) just make the rescheduling behavior in some way configurable,
> so it is not needed to override at all?

Hi Stefan,

I took a more detailed look at the package (tried both patches), and I 
figured the most acceptable solution was probably a little refactoring.

So, how? Since the class previously didn't require any configuration, 
I'd like to keep things that way. After all, it is still a pretty simple 
tool, for good reason.

Yet I agree just making a few random fields / methods protected is ugly 
because it makes the next person to look at the code scratch his head. 
The package implementation is pretty well-hidden, which is normally a 
good thing to do (imo) until you find you need to expose it. Since we 
now have found that need, I figured we'd just expose it.

Could you please take a look at the changes I made to the class and 
lemme know if this works for you?

- Leo

PS: the fact that I didn't apply your patches as-sent does not mean they 
were not valuable in figuring out what to do nor that you should refrain 
from sending them in for any future issues :D

To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message