avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Hammant <Paul_Hamm...@yahoo.com>
Subject Re: AW: Statusable
Date Fri, 29 Mar 2002 18:49:35 GMT
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:Steve.Short@PostX.com]
>>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:Paul_Hammant@yahoo.com]
>>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:leosimons@apache.org]
>>>>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:Paul_Hammant@yahoo.com]
>>>>>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:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
>>>>
>>>>>For additional commands, e-mail:
>>>>>
>>>><mailto:avalon-phoenix-dev-help@jakarta.apache.org>
>>>>
>>>>>
>>>>
>>>>
>>>>--
>>>>To unsubscribe, e-mail:
>>>><mailto:avalon-phoenix-dev-> unsubscribe@jakarta.apache.org>
>>>>
>>>>For additional commands,
>>>>e-mail: <mailto:avalon-phoenix-dev-help@jakarta.apache.org>
>>>>
>>>>
>>>>
>>>>--
>>>>To unsubscribe, e-mail:
>>>><mailto:avalon-phoenix-dev-> unsubscribe@jakarta.apache.org>
>>>>
>>>>For additional commands,
>>>>e-mail: <mailto:avalon-phoenix-dev-help@jakarta.apache.org>
>>>>
>>>>
>>>
>>>--
>>>To unsubscribe, e-mail:
>>>
>><mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
>>
>>>For additional commands, e-mail:
>>>
>><mailto:avalon-phoenix-dev-help@jakarta.apache.org>
>>
>>>
>>>
>>
>>
>>
>>--
>>To unsubscribe, e-mail:
>><mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
>>For additional commands, e-mail:
>><mailto:avalon-phoenix-dev-help@jakarta.apache.org>
>>
>>--
>>To unsubscribe, e-mail:
>>
><mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail:
><mailto:avalon-phoenix-dev-help@jakarta.apache.org>
>
>
>
>--
>To unsubscribe, e-mail:   <mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:avalon-phoenix-dev-help@jakarta.apache.org>
>
>
>




--
To unsubscribe, e-mail:   <mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-phoenix-dev-help@jakarta.apache.org>


Mime
View raw message