Is there a way within an appender to get the original object logged?  In 
log4net we call LoggingEvent.MessageObject.  In log4j2 it doesn't seem as 
straight forward.  A LogEvent object has a getMessage() method but I assume 
that's some sort of wrapper around the object that was logged.  We currently 
have code which gets our complex object which was logged by calling 
getParameters() and checking those objects against the interface our object 
implements.  However, if a simple string was logged how do we get that?  Can we 
always count on the zeroth element of the parameters array to be the original 
object that was logged?

Thanks,
Nick

> Subject: Re: StatusLogger
> From: ralph.go...@dslextreme.com
> Date: Fri, 20 Nov 2015 12:08:38 -0700
> To: log4j-user@logging.apache.org
> 
> OK - so it sounds like you are fine.
> 
> Ralph
> 
> 
> > On Nov 20, 2015, at 11:24 AM, Nicholas Duane <nic...@msn.com> wrote:
> > 
> > That's what we're doing.  The appender it writing to a logger and via the 
> > configuration we have that going to this http endpoint.  We're careful to 
> > ensure that the events raised by our appender don't come back to itself.
> > 
> > Thanks,
> > Nick
> > 
> >> Subject: Re: StatusLogger
> >> From: ralph.go...@dslextreme.com
> >> Date: Fri, 20 Nov 2015 11:04:57 -0700
> >> To: log4j-user@logging.apache.org
> >> 
> >> You can also use a normal logger in your appender for stuff that will 
> >> happen at runtime. You just have to be aware that if you have things 
> >> configured incorrectly that may result in a loop - at which point Log4j 
> >> will detect it and ignore those logging events.
> >> 
> >> Ralph
> >> 
> >>> On Nov 20, 2015, at 10:55 AM, Nicholas Duane <nic...@msn.com> wrote:
> >>> 
> >>> We're attempting to capture error, or info, events that our plugins 
> >>> raise.  For instance, we wrote a domain sockets appender.  If that domain 
> >>> sockets appender has trouble connecting to the domain socket we'd like to 
> >>> know about it.  In addition, we'd like to know about it centrally so that 
> >>> we don't have to monitor each of the boxes our code is running on.  We 
> >>> therefore have a "logging" appender which writes to an http endpoint.  
> >>> The log messages our plugins emit will get forwarded to this logging 
> >>> appender (via the configuration) in hopes to get these issues to a 
> >>> central location.  Of course if the http appender has trouble 
> >>> communicating with the http endpoint there's not much we can report on 
> >>> that, though I guess we could write to the StatusLogger at that point.
> >>> 
> >>> I hope I explained it well enough so that you understand what it is we're 
> >>> trying to do.
> >>> 
> >>> Thanks,
> >>> Nick
> >>> 
> >>>> Subject: Re: StatusLogger
> >>>> From: ralph.go...@dslextreme.com
> >>>> Date: Fri, 20 Nov 2015 10:16:17 -0700
> >>>> To: log4j-user@logging.apache.org
> >>>> 
> >>>> What do you mean by “capture the events from our appenders”?  The 
> >>>> StatusLogger is primarily used during configuration or to log errors 
> >>>> that occur in the appender. If you are trying to capture the events 
> >>>> being logged that sounds a bit odd as that is the purpose of an appender.
> >>>> 
> >>>> If you want to capture all the Log4j status logger output you can 
> >>>> specify a destination on the configuration element. The output will then 
> >>>> be written to that location instead of to stdout.
> >>>> 
> >>>> Ralph
> >>>> 
> >>>>> On Nov 20, 2015, at 8:01 AM, Nicholas Duane <nic...@msn.com> wrote:
> >>>>> 
> >>>>> The code happens to be a log4j2 appender, so it sounds like you're 
> >>>>> saying we should be using the StatusLogger, correct?  The issue is that 
> >>>>> we want to capture the events from our appenders to a central location.
> >>>>> 
> >>>>> Thanks,
> >>>>> Nick
> >>>>> 
> >>>>>> Subject: Re: StatusLogger
> >>>>>> From: ralph.go...@dslextreme.com
> >>>>>> Date: Thu, 19 Nov 2015 19:01:45 -0700
> >>>>>> To: log4j-user@logging.apache.org
> >>>>>> 
> >>>>>> Yes, the StatusLogger is how Log4j logs things that happen within 
> >>>>>> Log4j itself. If you are writing plugins for Log4j those should also 
> >>>>>> use the StatusLogger as they effectively become part of Log4j. If the 
> >>>>>> are regular application code then they should not use the StatusLogger.
> >>>>>> 
> >>>>>> Although the StatusLogger uses the same API as the Log4j API its 
> >>>>>> implementation is quite different and much more limited in what can be 
> >>>>>> done with the output.
> >>>>>> 
> >>>>>> The StatusLogger implementation doesn’t have Appenders. Instead it has 
> >>>>>> StatusListeners that receive the events. The only listeners provided 
> >>>>>> with Log4j are the StatusConsoleListener, which writes events to 
> >>>>>> stdout or a PrintStream, and StatusLoggerAdmin, which makes events 
> >>>>>> available over JMX.
> >>>>>> 
> >>>>>> Ralph
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>>> On Nov 19, 2015, at 6:33 PM, Nicholas Duane <nic...@msn.com> wrote:
> >>>>>>> 
> >>>>>>> I'm trying to get information on the StatusLogger.  I've searched and 
> >>>>>>> so far the log4j docs say:
> >>>>>>> 
> >>>>>>> "Records events that occur in the logging system."
> >>>>>>> 
> >>>>>>> There are also a bunch of articles related to people having problems 
> >>>>>>> with the StatusLogger.  I'm just looking to find out what it is.  It 
> >>>>>>> appears it's somewhat of an "internal" logger that log4j (log4j2) 
> >>>>>>> uses to log internal events.  One reason I'm looking into this is 
> >>>>>>> because I see some code in one of our projects in which the class is 
> >>>>>>> logging to the StatusLogger.  I assume we shouldn't be doing this.
> >>>>>>> 
> >>>>>>> Is the StatusLogger used in log4j2?  In one post I read that the 
> >>>>>>> "status" attribute controls the level.  Can I set the appender for 
> >>>>>>> the StatusLogger?
> >>>>>>> 
> >>>>>>> Thanks,
> >>>>>>> Nick
> >>>>>>>                                         
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> >>>>>> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> >>>>>> 
> >>>>>                                           
> >>>> 
> >>>> 
> >>>> 
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> >>>> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> >>>> 
> >>>                                     
> >> 
> >> 
> >> 
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> >> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> >> 
> >                                       
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 
                                          

Reply via email to