avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Simons" <m...@leosimons.com>
Subject RE: AW: Statusable
Date Fri, 29 Mar 2002 18:30:11 GMT
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>


Mime
View raw message