You would call logMessage and pass the Message object. Ralph
> On Nov 30, 2015, at 1:19 PM, Nicholas Duane <[email protected]> wrote: > > As I mentioned, what we're trying to do is capture events from our appenders. > However, the part I didn't mention is that we *might* want to also > "failover" the event which was sent to our appender to another appender. In > that case we want to log the event our appender received to our appender's > logger. I'm therefore trying to find out how to get the original object > logged as I assume I don't want to pass the logEvent to the logger. > > We've noticed that when we log one of our complex objects, such as: > > IEvent evnt = Event.create(...); > logger.info(evnt); > > that our evnt object happens to be one of the parameters in the logEvent's > message object. I'm trying to see how I can "resubmit" this event to the > appender's logger in a consistent fashion regardless of how it was originally > logged. So whether I do the above or: > > logger.Error("this is my error message"); > > within the appender I want to "failover" this event to the appender's logger. > Is that possible? > > Thanks, > Nick > >> Subject: Re: StatusLogger >> From: [email protected] >> Date: Mon, 30 Nov 2015 13:01:23 -0700 >> To: [email protected] >> >> 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 <[email protected]> >>> 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 <[email protected]> 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: [email protected] >>>>> Date: Mon, 30 Nov 2015 08:30:37 -0700 >>>>> To: [email protected] >>>>> >>>>> 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 <[email protected]> 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: [email protected] >>>>>>> Date: Fri, 20 Nov 2015 12:08:38 -0700 >>>>>>> To: [email protected] >>>>>>> >>>>>>> OK - so it sounds like you are fine. >>>>>>> >>>>>>> Ralph >>>>>>> >>>>>>> >>>>>>>> On Nov 20, 2015, at 11:24 AM, Nicholas Duane <[email protected]> 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: [email protected] >>>>>>>>> Date: Fri, 20 Nov 2015 11:04:57 -0700 >>>>>>>>> To: [email protected] >>>>>>>>> >>>>>>>>> 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 <[email protected]> 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: [email protected] >>>>>>>>>>> Date: Fri, 20 Nov 2015 10:16:17 -0700 >>>>>>>>>>> To: [email protected] >>>>>>>>>>> >>>>>>>>>>> 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 <[email protected]> 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: [email protected] >>>>>>>>>>>>> Date: Thu, 19 Nov 2015 19:01:45 -0700 >>>>>>>>>>>>> To: [email protected] >>>>>>>>>>>>> >>>>>>>>>>>>> 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 <[email protected]> >>>>>>>>>>>>>> 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: [email protected] >>>>>>>>>>>>> For additional commands, e-mail: >>>>>>>>>>>>> [email protected] >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>>>>>> For additional commands, e-mail: [email protected] >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>>>> For additional commands, e-mail: [email protected] >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>> For additional commands, e-mail: [email protected] >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
