Eung-ju,
Sorry dude. I knew your were trading behind some cryptic email address. It was 'colus' of course.
- Paul
Emperor is not me. ;-)
----- Original Message ----- From: "Paul Hammant" <[EMAIL PROTECTED]> To: "Avalon-Phoenix Developers List" <[email protected]> Sent: Friday, March 29, 2002 9:30 PM Subject: Re: AW: Statusable
Eung-Ju,
Yes that would work, but the secondary need would be to buffer things for repeated use in a management app.
Maybe I'll just keep using System.out :-) It is not a problem ...
- Paul
Why not use a separate Logger to output to console? So the newbies wouldn't have to do anything, and you could easily disable console logging or redirect it to a file.
-----Urspr�ngliche Nachricht----- Von: Leo Simons [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 28. M�rz 2002 21:37 An: Avalon-Phoenix Developers List Betreff: RE: Statusable
I'm +1 but as this would break logger binary compatibility it requires a new release of logger, and maybe also of excalibur/ framework (not exactly sure where the changes are neccessary?).
So we might still need to keep writing to System.out for now... you volunteering to look into this? ;)
Also, did Pete ever reply to the question below? Pete? He is king-of-the-logkit of course, so we need his infinite wisdom on this :P
cheers,
- Leo
-----Oorspronkelijk bericht----- Van: Paul Hammant [mailto:[EMAIL PROTECTED] Verzonden: Thursday, March 28, 2002 9:05 PM Aan: Avalon-Phoenix Developers List Onderwerp: Re: Statusable
I think this is worth re-opening.
Reason? Well we are about to have SAR files downloadable from the website and drop into an arbitary Phoneix. In terms of the "five second test", it would be handy if the blocks could offer
some advice
after start().
For example if a product uses Jo! it may want to say.
"HTTP Service mounted on port 8080"
At the moment I find myself writing to System.out to help
the newbie
know what they should do after launching Phoenix with an app. It would be nice if there were some controlled way of output
such status
info for a block.
The original idea was to have Statusable
setStatus(String msg) ],
but that was rightly shot down as there is much overlap
with Logger.
If Logger were to have a new method for setting of status (or priority) and the status, as well as being output to the
log target,
were buffered by Phoenix for other use :
1) later retrieval by a management console, webapp or GUI. 2) after system startup, a once only outputting of statii to the console (for the newbie)
Thoughts?
- Paul
Hi,
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 ;-)
How about extending the Priority by adding a STATUS level and do logger.log(XXXPriority.STATUS, message)? True, Priority is final
but I don't
see any reason why it is like that. Why would you use
logger.log(..) method
then?
Mircea
-- To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
-- To unsubscribe, e-mail: <mailto:avalon-phoenix-dev-> [EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- 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]>
-- To unsubscribe, e-mail:
<mailto:[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]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
