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:[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]>
