Extras. I use them to build properties from a Map, add fixed
properties to all events coming off the appender. I could see people
using it to sanitize thread names,parts of thowables or messages as
well.
Scott
On Sep 23, 2011, at 7:33 AM, Ralph Goers <ralph.go...@dslextreme.com>
wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
