To elaborate a bit more, if you call Log4j to log just a String then a SimpleMessage will be passed in. If you log a String with parameters then you will have either a ParameterizedMessage (the default) or a StringFormattedMessage, MessageFormatMessage or FormattedMessage, depending on the MessageFactory specified on the Logger. It also could be an RFC5424 Message or a MapMessage in which case the Message will contain a Map of data elements. Users can also create their own Message types.
Ralph > On Nov 30, 2015, at 12:46 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > From Log4j’s perspective, what is logged is the Message. Each message may > have a different way of encapsulating its information. > > Ralph > >> On Nov 30, 2015, at 8:33 AM, Nicholas Duane <nic...@msn.com> wrote: >> >> I'm not necessarily after the string. I'm trying to get the original object >> that was passed to one of the logging methods. It could have been a string >> or some complex object. >> >> Thanks, >> Nick >> >>> Subject: Re: StatusLogger >>> From: ralph.go...@dslextreme.com >>> Date: Mon, 30 Nov 2015 08:30:37 -0700 >>> To: log4j-user@logging.apache.org >>> >>> Log4j2 logs Message objects. The object being logged is contained within >>> the message. You would normally call getFormattedMessage() to get the >>> message String if that is what you are after. >>> >>> Ralph >>> >>>> On Nov 30, 2015, at 7:10 AM, Nicholas Duane <nic...@msn.com> wrote: >>>> >>>> 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 >>>>> >>>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> 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
