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....
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)
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.......
Emperor is making the same point about similarities with Logging. I am not so sure there is that overlap with the current Logger.class.
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
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
