You are viewing a plain text version of this content. The canonical link for it is here.
Posted to phoenix-dev@avalon.apache.org by Leo Simons <le...@apache.org> on 2002/10/20 16:37:25 UTC
an apology
Dear all,
it has been brought to my attention I have been overstepping some moral
guidelines of The Apache Way with regard to voting (among other things)
behaviour. I'd like to apologize for that and hope there's not too many
harsh feelings. I'm still learning the ropes, as I think the saying
goes... :)
cheers,
Leo Simons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Scheduler block enhancements
Posted by 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
Posted by 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>
Scheduler block enhancements
Posted by 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>
Phoenix - release 4.0.1
Posted by Paul Hammant <Pa...@yahoo.com>.
Folks,
Phoenix 4.0.1 is now available.
http://jakarta.apache.org/builds/jakarta-avalon-phoenix/release/v4.0.1/
Changes:-
* A backwards compatible logger.
* MX4J 1.1.1 beta1.
* Better wrapper support for those wanting to thunk phoenix into Windows
services or Linux equiv with restart capability.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Phoenix - release 4.0.1
Posted by Paul Hammant <Pa...@yahoo.com>.
Folks,
Phoenix 4.0.1 is now available.
http://jakarta.apache.org/builds/jakarta-avalon-phoenix/release/v4.0.1/
Changes:-
* A backwards compatible logger.
* MX4J 1.1.1 beta1.
* Better wrapper support for those wanting to thunk phoenix into Windows
services or Linux equiv with restart capability.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: an apology
Posted by Stephen McConnell <mc...@apache.org>.
Leo Simons wrote:
>Dear all,
>
>it has been brought to my attention I have been overstepping some moral
>guidelines of The Apache Way with regard to voting (among other things)
>behaviour. I'd like to apologize for that and hope there's not too many
>harsh feelings. I'm still learning the ropes, as I think the saying
>goes... :)
>
Sorry Leo - I can't accept an apology when there's nothing to apologize
about. I haven't seen anything improper in your actions - in fact it's
quite the opposite - I'm not the only one who holds you high esteem.
Whatever you do - don't change!!
On more practical matters - the much discussed "Apache Way" (refer reorg
list discussions) is somewhere between myth and reality and heavily
biased by whoever is telling you the story. This has evidenced by many
of the messages posted to the reorg list. It appears to me that the
"Apache Way" is much more in the minds of the Apache members that have
been here longer - something more of a culture - and progressively
documented. Unfortunately the documentation that does exist leaves lots
of holes which assume pragmatic management via something called a PMC.
In the Avalon case that context should be coming from the Jakarta PMC
however the relationship between Jakarta and Avalon is much more a case
of casual observation. The direction discussed on the reorg list directly
addresses this issue across the whole of Apache by pushing responsibility
and accountability down to projects such as Avalon - challenging us to take
responsibility for evolution, process and content generated by the Avalon
project - and embracing accountability towards the Avalon community and
the Apache Board. This means a potential future based on open and
responsible management under an Avalon PMC - something that I really hope
will come together with the direct participation of people like yourself -
people concerned about the Avalon community, our development, and the
quality of the products we produce.
Keep up the good work!
Cheers, Steve.
>cheers,
>
>Leo Simons
>
>
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: an apology
Posted by Stephen McConnell <mc...@apache.org>.
Leo Simons wrote:
>Dear all,
>
>it has been brought to my attention I have been overstepping some moral
>guidelines of The Apache Way with regard to voting (among other things)
>behaviour. I'd like to apologize for that and hope there's not too many
>harsh feelings. I'm still learning the ropes, as I think the saying
>goes... :)
>
Sorry Leo - I can't accept an apology when there's nothing to apologize
about. I haven't seen anything improper in your actions - in fact it's
quite the opposite - I'm not the only one who holds you high esteem.
Whatever you do - don't change!!
On more practical matters - the much discussed "Apache Way" (refer reorg
list discussions) is somewhere between myth and reality and heavily
biased by whoever is telling you the story. This has evidenced by many
of the messages posted to the reorg list. It appears to me that the
"Apache Way" is much more in the minds of the Apache members that have
been here longer - something more of a culture - and progressively
documented. Unfortunately the documentation that does exist leaves lots
of holes which assume pragmatic management via something called a PMC.
In the Avalon case that context should be coming from the Jakarta PMC
however the relationship between Jakarta and Avalon is much more a case
of casual observation. The direction discussed on the reorg list directly
addresses this issue across the whole of Apache by pushing responsibility
and accountability down to projects such as Avalon - challenging us to take
responsibility for evolution, process and content generated by the Avalon
project - and embracing accountability towards the Avalon community and
the Apache Board. This means a potential future based on open and
responsible management under an Avalon PMC - something that I really hope
will come together with the direct participation of people like yourself -
people concerned about the Avalon community, our development, and the
quality of the products we produce.
Keep up the good work!
Cheers, Steve.
>cheers,
>
>Leo Simons
>
>
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Phoenix - release 4.0.1
Posted by Paul Hammant <Pa...@yahoo.com>.
Folks,
Phoenix 4.0.1 is now available.
http://jakarta.apache.org/builds/jakarta-avalon-phoenix/release/v4.0.1/
Changes:-
* A backwards compatible logger.
* MX4J 1.1.1 beta1.
* Better wrapper support for those wanting to thunk phoenix into Windows
services or Linux equiv with restart capability.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: an apology
Posted by Leo Simons <le...@apache.org>.
On Tue, 2002-10-22 at 04:00, Berin Loritsch wrote:
> Peter Donald wrote:
> > np. You should have seen some of the uglier things I did earlier on (here and
> > in Ant-land). I am sure that Berin can tell you a tale or two ;)
>
> We've all made mistakes. I'm sure you guys have noticed me getting a little less
> patient with my responses during times when I was under great stress. Just as
> long as we learn from our mistakes it is all good.
always learning. always learning :D
> BTW, which voting behaviors are you referring to?
Did I respond yet? Neeeeed sleeeeep.....
Anyway, an example that springs to mind right now is where I threw a -1
on something proposed on phoenix-dev (I can't really remember what it's
about atm...), only to find out that the questions I posed had been
thoroughly answered and I had not been paying close enough attention to
notice. Stuff like that.
g'night,
Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: an apology
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> np. You should have seen some of the uglier things I did earlier on (here and
> in Ant-land). I am sure that Berin can tell you a tale or two ;)
We've all made mistakes. I'm sure you guys have noticed me getting a little less
patient with my responses during times when I was under great stress. Just as
long as we learn from our mistakes it is all good.
BTW, which voting behaviors are you referring to?
>
> On Mon, 21 Oct 2002 00:37, Leo Simons wrote:
>
>>Dear all,
>>
>>it has been brought to my attention I have been overstepping some moral
>>guidelines of The Apache Way with regard to voting (among other things)
>>behaviour. I'd like to apologize for that and hope there's not too many
>>harsh feelings. I'm still learning the ropes, as I think the saying
>>goes... :)
>>
>>cheers,
>>
>>Leo Simons
>
>
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: an apology
Posted by Peter Donald <pe...@apache.org>.
np. You should have seen some of the uglier things I did earlier on (here and
in Ant-land). I am sure that Berin can tell you a tale or two ;)
On Mon, 21 Oct 2002 00:37, Leo Simons wrote:
> Dear all,
>
> it has been brought to my attention I have been overstepping some moral
> guidelines of The Apache Way with regard to voting (among other things)
> behaviour. I'd like to apologize for that and hope there's not too many
> harsh feelings. I'm still learning the ropes, as I think the saying
> goes... :)
>
> cheers,
>
> Leo Simons
--
Cheers,
Peter Donald
-------------------------------------------------------------
| Egoism is the drug that soothes the pain of stupidity. |
-------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>