Where are those located? Ralph
On Sep 23, 2011, at 7:29 AM, Scott Deboy wrote: > Can you look at rewriteappender and rewritepolicy will fit in? Ability to > modify the event message and add properties and possibly anything else via > configuration. > > > > On Sep 23, 2011, at 12:37 AM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > >> >> On Sep 22, 2011, at 10:16 PM, Curt Arnold wrote: >> >>> Been lurking and watching the thread, wanted to throw some comments out >>> without fully following the thread. Take everything with a grain of salt. >> >> Why? Your input is just as valuable as everyone else's. >> >>> >>> log4j 1.2's AsyncAppender does a bit of this by calling all sorts of >>> methods to force the lazy initialization of the event prior to the event >>> being queued for processing by the worker thread. This can result in a lot >>> of unnecessary work on the calling thread copying things like the MDC that >>> might but might not be used in the eventual message formatting. >> >> For some reason I haven't gotten around to the AsyncAppender. I'm afraid >> some copying of data when generating the LogEvent is inevitable. >> >>> >>> Performing the rendering of the message on the calling thread is also not >>> desirable since things like formatting floating point numbers can be >>> surprisingly expensive. >> >> One advantage of the Message interface is that it can provide information >> that can help determine when it should be rendered. For example, in addition >> to the initialize method John proposed for the DeferredMessage it could also >> indicate when it should be deferred to. Of course, Messages never need to >> format themselves until getFormattedMessage is called. >> >>> >>> In some of my earlier design experiments, I was very fond of having the >>> formatter/layout object supporting a two phase approach where the layout >>> had an opportunity to "extract" from the logging event on the calling >>> thread and then process the extracted information later on the worker >>> thread. The extraction method would be responsible to assemble the >>> information that it needed into an arbitrary immutable object that would be >>> passed blindly by the framework to the formatting phase at the proper time. >>> The implementation had the choice of whether it wanted to render all the >>> way to String on the calling thread (say if it were cheap) on do the >>> minimum to get immutable objects in the calling thread and do all the heavy >>> lifting on the worker thread. >> >> I'm not sure I see the benefit of creating another object. You still need >> the LogEvent. Most of the work to insure the LogEvent can be passed to >> another thread really needs to be done anyway. Currently the constructor >> copies the MDC and NDC and a ThrowableProxy is constructed if a Throwable is >> present. About the only things that aren't being done then is the setting of >> the caller's StackTraceElement and setting the name of the current thread. >> It is a simple matter to have the AsyncAppender cause those to be set. >> >> FWIW, the LogEvent should be immutable from the perspective of anything >> using it. Since LogEvent is an interface and only exposes get methods this >> would be true, except that getContextMap and getContextStack don't say they >> return unmodifiable objects and they implementation isn't returning >> immutable objects. They should. >> >>> >>> Without getting the layout participating, you almost will be doing >>> unnecessary work on the calling thread. >> >> I don't necessarily disagree with this part. For example, the Converters >> that deal with the caller's location could call LogEvent.getSource during >> the first call to make sure the required information in the LogEvent is >> captured. Of course, they would call that same method during the rendering >> but that second call would be very inexpensive. >> >>> >>> I fleshed this approach out several years ago at >>> https://svn.apache.org/repos/asf/logging/sandbox/experimental/pattern-layout >>> if anyone wants to take a look for ideas. >> >> I'll take a look at this. >> >> Ralph >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org >> For additional commands, e-mail: log4j-dev-h...@logging.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-dev-h...@logging.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
