Leo
Yup, nethier should depend in the other (JMX / Phoenix). However when used together there should be decent interoperation.
If there were a Statusable IoC interface or Status like methods or priorities in Logger, then making them visible in JMX when present would be good.
To be honest, I do not think we are ready to do anything on this yet. In some months it may be different.
- Paul
Perhaps it would, except that we want JMX to be optional in phoenix. Messages like this should function even when it is disabled.
JMX is about management but can do much more. We try to only use it for management. It does management relatively well, and other stuff with varying degrees of success.
I just made this up so I may be wrong, but since I did a lot of the initial JMX stuff I may still be right.
Sorry if this is confusing, JMX and phoenix is still a work in progress :)
regards,
- Leo
-----Oorspronkelijk bericht----- Van: Steve Short [mailto:[EMAIL PROTECTED] Verzonden: Friday, March 29, 2002 5:27 PM Aan: 'Avalon-Phoenix Developers List' Onderwerp: RE: AW: Statusable
I'm not sure where JMX fits in to the Phoenix picture, but isn't this where JMX notification model would come in useful? You can define a notification type 'status' (or 'org.apache.jmx.notification.status ?) and then register listeners appropriate to your needs, including a listener that simply calls a Logger.
Steve
-----Original Message----- From: Paul Hammant [mailto:[EMAIL PROTECTED] Sent: Friday, March 29, 2002 4:30 AM To: Avalon-Phoenix Developers List 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]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
