My answer here is, it depends. The RewriteAppender modifies a copy of the LogEvent and then passes that copy to subordinate Appenders. See http://logging.apache.org/log4j/2.x/manual/appenders.html#RewriteAppender. Any other Appenders that are called will still get the original, unmodified, LogEvent.
On the other hand, if you purposely want to place a filter on a LoggerConfig that modifies the LogEvent for all its Appenders (and any parent LoggerConfigs) you can do that by doing event.getContextMap().put(). You are correct that the LogEvent javadoc is misleading in that it says you will get a copy when you won't. In the implementation of getContextMap and getContextStack in Log4jLogEvent has @doubt statements added by Curt where he expressed concern that the actual Map and Stack were being returned (meaning they could be modified by Appenders, Filters, etc). I've left that in so this could be discussed. I believe they need to return the actual Map and Stack so that the use cases you describe can be supported. It also performs faster than having to copy the Map or Stack each time a component wants to manipulate them in some way. I also have no problem with Appenders, Filters, etc. modifying the LogEvent as long as they document it. Ralph On Aug 6, 2012, at 8:51 AM, Scott Deboy wrote: > It is relatively common in log4j and extras for both appenders and receivers > to add properties to events (see the use of the 'application' socketappender > property in log4j). > > There is an implementation detail in log4j's LoggingEvent that caused me to > have to 'wrap' the logging event for use in Chainsaw: LoggingEvent provides a > read-only copy of properties. > > Chainsaw uses the properties mechanism itself in order to support the dynamic > rendering capabilities it provides. Events in Chainsaw can be rendered > differently based on the time delta from the previous displayed row, which > changes when the display filter is updated. > > If you can provide a way for me to update properties, I'd use whatever API > you gave me. > > Scott > > On Mon, Aug 6, 2012 at 12:42 AM, Ralph Goers <[email protected]> > wrote: > If I understand what you are doing correctly, you are receiving a serialized > LogEvent however it may have been delivered, possibly embellishing it and > then passing it on to be logged. If that is correct you are going to have to > be tied to the implementation (i.e. core) as that is the only place a > LogEvent exists. However, ideally core should provide what you need in a form > such as AbstractServer but with a hook to let you modify the event. > > Would that do what you want? > > Yes, I'm sure the javadoc could be improved. I would request you either open > a Jira, fix it, or both. > > Ralph > > > On Aug 6, 2012, at 12:31 AM, Scott Deboy wrote: > >> ok, LogEvent is an interface, but in core. And I'm coding the receivers >> against that interface, which says it returns a copy but does not in >> Log4jLogEvent: >> >> /** >> * Get the MDC data. >> * >> * @return A copy of the Mapped Diagnostic Context or null. >> */ >> >> >> By the way, the class javadoc for ThreadContext is incomplete or incorrect. >> >> /** >> * The ThreadContext allows applications to store information either in a Map >> * <p/> >> >> >> So, I need a new API that doesn't return a copy? Or do I have to create a >> copy of an event when I add properties? >> >> On Sun, Aug 5, 2012 at 11:21 PM, Ralph Goers <[email protected]> >> wrote: >> I'm confused. Although the javadoc could be better >> http://logging.apache.org/log4j/2.x/log4j-api/apidocs/org/apache/logging/log4j/ThreadContext.html#getContext() >> and >> http://logging.apache.org/log4j/2.x/log4j-api/apidocs/org/apache/logging/log4j/ThreadContext.html#getContext() >> both say they return a copy. ThreadContext doesn't have methods named >> getContextMap or getContextStack. >> >> Note that the LogEvent is not available in the API. >> >> Ralph >> >> On Aug 5, 2012, at 10:45 PM, Scott Deboy wrote: >> >>> My point was really the contract in the API javadoc should be updated and >>> we should implement that contract..if we neeed new APIs, that's ok..or if >>> I'm forced to create a new Log4jevent I'll deal with the contract. >>> >>> Scott >>> >>> On Sun, Aug 5, 2012 at 9:32 PM, Ralph Goers <[email protected]> >>> wrote: >>> In the Log4j 2 API the getContext and cloneStack methods of ThreadContext >>> return copies of the Map and Stack. In the LogEvent in impl getContextMap >>> and getContextStack return the actual Map and Stack that are in the >>> LogEvent. Copying them would be too expensive. >>> >>> I don't know that there are any components yet that can add, delete or >>> modify MDC keys or values, but i know that such a feature would be desired. >>> That said, the RewriteAppender uses the RewritePolicy which creates a new >>> LogEvent. >>> >>> Ralph >>> >>> On Aug 5, 2012, at 7:16 PM, Scott Deboy wrote: >>> >>> > Chainsaw and some Receivers add properties to events to support tracking, >>> > for example, log4jid is added by Chainsaw. >>> > >>> > One thing that needs to be clarified in the api contract is whether or >>> > not getContextMap and getContextStack give you a copy of the map/stack or >>> > the original, as again, Chainsaw and others will need to use some api to >>> > modify those values. >>> > >>> > Scott >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> > >
