Mailing-List: contact dev-help@avalon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <dev@avalon.apache.org>
To: dev@avalon.apache.org
From: Leo Simons <leosimons@apache.org>
Subject: Re: [Components: TimeScheduler] TimeScheduler behaviour with periodic
 triggers
Date: Sat, 23 Aug 2003 11:47:54 +0200
Lines: 44
Message-ID: <bi7d8f$ivl$1@sea.gmane.org>
References: <8CB263A54D013842A2AF262CE9952ACB14BFF2@feanor.pro-vision.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.3) Gecko/20030312
In-Reply-To: <8CB263A54D013842A2AF262CE9952ACB14BFF2@feanor.pro-vision.de>
Sender: news <news@sea.gmane.org>

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