On May 22, 2010, at 10:50 AM, Ralph Goers wrote:
>
>>
>> Also, I have had an issue where the I wanted the toString() method on the
>> object to be logged to be delayed as much as possible (somewhat helped with
>> the {}-construct in slf4j). This might be doable with a specific log
>> interface.
>
> That is exactly what Message does.
>
My thoughts, but not sure how much of this got into my earlier code, was to
have a distinct extraction phase that occur synchronously with the logging call
that would extract all info needed for a completion phase that could occur
either immediately or be deferred. The extraction phase would need to extract
any info from the call into immutable objects so state change, for example
mutable message parameters, before the completion stage would not change the
resulting log.
A example where this would be useful is logging floating point numbers. It can
be surprisingly expensive to format floating point numbers, so it is highly
beneficial to extract all the pieces needed for the formatting into an
immutable package during the synchronous extraction phase and then do the
formatting in the asynchronous completion phase.
The AsynchronousAppender in log4j requires trying to freeze LoggingEvent which
is still subject to message objects changing underneath it. Also it generally
perform unnecessary actions in freezing everything in the LoggingEvent even
though much of it will not be used.
The framework should be designed to separate the parts required to be
synchronous (that is anything dealing with external objects) from the parts
that can be deferred.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
