Scheduler block enhancements

[Mauro Talevi <ma...@aquilonia.org>]

Hi,

in using the cornerstone scheduler block, the following useful 
enhancements spring to mind:

1.  PeriodicTimeTrigger - it would be useful to have a constructor with 
which to
specify the trigger time directly,  as a oneoff triggered event.  
At present, this can be done by calculating the offset from the trigger 
time and the current time
and using -1 as the period.  
The triggerTime variable is already used privately by the class, so I 
ask if there was any
reason not to expose the constructor to set it.
Perhaps, one might argue that it make it a non-periodic trigger any more 
and it should
be implemented in a separate TimeTrigger, but I'd be more inclined to 
consider it a specific case of
PeriodicTimeTrigger.

2.  TimeScheduler - how about adding to the interface methods to manage 
the list of Triggers that have
already been added, eg

public String[] getTriggerNames();

so that one can check what has been added already.  
Also, some method that return the information about the trigger
There already is a method

private TimeScheduleEntry getEntry(String name);  

that could be made public - but TimeScheduledEntry should be promoted to 
the public class in services.scheduler.

Any thoughts?  If there are no design objections I could implement the 
enhancements and send in a patch.
The PeriodicTimeTrigger could also do with enhanced javadocs.

Cheers, Mauro





--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Scheduler block enhancements

[Mauro Talevi <ma...@aquilonia.org>]

Peter,

Peter Donald wrote:

>I would prefer a OneTimeTrigger class. It would mean that the code for the 
>class is simpler and easier to understand IMHO.
>
ok - the separate class does have the advantage of being more intuitive 
as to its purpose

>Instead of exposing TimeScheduleEntry which holds lots of implementation 
>details that should not be exposed. It may be better to return a specially 
>constructed object which people can see detail of. Something like
>
>public class ScheduleEntry
>{
>  String name; //name registered under
>  Trigger trigger; //trigger supplied
>  long nextTime; 
>}
>
>This allows us to change implementation of TimeScheduleEntry without effecting 
>users. It also stops users trying to manipulate Targets that have been 
>scheduled.
>
>Like?
>
yes - but perhaps it would be better to make ScheduleEntry an interface 
that TimeScheduleEntry implements.
Then in the implementation one can construct and return a new object 
that implements it (that would ensure as you
say that no one has access to the implementation details of 
TimeScheduleEntry) or if we do not want to create
too many objects we could return ScheduleEntry with the underlying 
implementation of  TimeScheduleEntry
(but clients would have to know it and typecast it).

Cheers, Mauro



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Scheduler block enhancements

[Peter Donald <pe...@apache.org>]

Hi Mauro,

On Wed, 23 Oct 2002 01:18, Mauro Talevi wrote:
> in using the cornerstone scheduler block, the following useful
> enhancements spring to mind:
>
> 1.  PeriodicTimeTrigger - it would be useful to have a constructor with
> which to
> specify the trigger time directly,  as a oneoff triggered event.
> At present, this can be done by calculating the offset from the trigger
> time and the current time
> and using -1 as the period.
> The triggerTime variable is already used privately by the class, so I
> ask if there was any
> reason not to expose the constructor to set it.
> Perhaps, one might argue that it make it a non-periodic trigger any more
> and it should
> be implemented in a separate TimeTrigger, but I'd be more inclined to
> consider it a specific case of
> PeriodicTimeTrigger.

I would prefer a OneTimeTrigger class. It would mean that the code for the 
class is simpler and easier to understand IMHO.

> 2.  TimeScheduler - how about adding to the interface methods to manage
> the list of Triggers that have
> already been added, eg
>
> public String[] getTriggerNames();

Works for me.

> so that one can check what has been added already.
> Also, some method that return the information about the trigger
> There already is a method
>
> private TimeScheduleEntry getEntry(String name);

Instead of exposing TimeScheduleEntry which holds lots of implementation 
details that should not be exposed. It may be better to return a specially 
constructed object which people can see detail of. Something like

public class ScheduleEntry
{
  String name; //name registered under
  Trigger trigger; //trigger supplied
  long nextTime; 
}

This allows us to change implementation of TimeScheduleEntry without effecting 
users. It also stops users trying to manipulate Targets that have been 
scheduled.

Like?

> Any thoughts?  If there are no design objections I could implement the
> enhancements and send in a patch.

that would be great.

> The PeriodicTimeTrigger could also do with enhanced javadocs.

That would be even better ;)

-- 
Cheers,

Peter Donald
---------------------------------------------------
"Therefore it can be said that victorious warriors 
win first, and then go to battle, while defeated 
warriors go to battle first, and then seek to win." 
              - Sun Tzu, the Art Of War
--------------------------------------------------- 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>