> -----Urspr�ngliche Nachricht----- > Von: Paul Hammant [mailto:[EMAIL PROTECTED] > 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-> [EMAIL PROTECTED]> > > For additional commands, > e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
