avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emperor" <DarkEmpe...@gmx.net>
Subject AW: Statusable
Date Tue, 05 Mar 2002 14:26:17 GMT


> -----Ursprüngliche Nachricht-----
> Von: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
> Gesendet: Montag, 4. März 2002 19:49
> An: Avalon-Phoenix Developers List
> Betreff: Re: Statusable
> 
> 
> Leo
> 
> >>Whilst porting the apps, I noted that there is no consitency as to
> >>what
> >>is printed to sys.out at startup of Phoenix.  It is clear 
> that some sort
> >>of message is needed because newbies, will be underwhelmed
> if nothing is
> >>printed.  I believe in the "five second test".  In use, if
> it is not
> >>apparent in the first five seconds that some tool is excellent, the
> >>potential user will dislike the tool.
> >>
> >
> >I am guessing the limit for potential phoenix users is slightly
> >higher... maybe 15 or so... ;-)
> >
> :-O
> 
> >>If we had..........
> >>
> >>interface Statusable {
> >>  void setStatusManager(StatusManager sm);
> >>}
> >>
> >>interface StatusManager {
> >>  void setStatus(String status);
> >>}
> >>
> >>At startup, the blocks launched could, if they wanted, keep
> the system
> >>advised on their status.  After Phoenix has invoked the
> last lifecycle
> >>method during a startup it may choose to dump a table of
> statii to the
> >>console.  Thus we have a standard output for each block.
> >>
> >>We also, in some future management console, have a
> refreshable table
> >>for
> >>blocks.  The idea is that this info supplements the
> concrete "started" &
> >>"initialized" types, with stuff like "listening on port 1234, 321
> >>transactions performed"
> >>
> >>Thoughts?  I'm also thinking this is not just useful for Phoenix....
> >>
> >
> >I agree we need this, but I'm unsure whether an additional lifecycle
> >method is the way to go. We don't want too many lifecycle methods... 
> >maybe a "reverse command line argument utility" or something 
> could be
> >available instead...
> >
> Don;t like the sound of that....
> 
> >
> >
> >I'm wondering about IoC...in the end, what you're doing is still
> >sending messages to system.out....also, what about handling 
> this using
> >std logging mechanisms.......
> >
> No Phoenix is buffering the states of blocks.  *One* impl of Phoenix
> Kernel chooses to dump them to the console (as well as still 
> buffer them 
> for state queries.
> 
> Emperor is making the same point about similarities with
> Logging.  I am 
> not so sure there is that overlap with the current Logger.class.

You can call me Nils ;)

> 
> If it had status(String st); as a method I might think it
> could do the 
> job.  I am not sure how we would stand on that addition given 
> the recent 
> backwards-compatability flamewars ;-)
> 
> >I should shut up for today, I guess...lack of coherence...
> >
> It is me (as usual) who lacks coherence...
> 
> - Paul
> 

What about the profiler/statistics/status mix? Having a kind of monitor
object associed with each block where you can create profiler points,
change status, and post (key-value formatted) statistics?

Just n idea... Which also acks of coherence ;)

> 
> --
> To unsubscribe, e-mail:   
> <mailto:avalon-phoenix-dev-> unsubscribe@jakarta.apache.org>
> 
> For additional commands,
> e-mail: <mailto:avalon-phoenix-dev-help@jakarta.apache.org>
> 
> 


--
To unsubscribe, e-mail:   <mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-phoenix-dev-help@jakarta.apache.org>


Mime
View raw message