logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Vasileff <john.li...@gmail.com>
Subject Re: log4j2 parameterized msg with throwable
Date Mon, 19 Sep 2011 20:20:57 GMT

On Sep 19, 2011, at 4:09 PM, ralph.goers @dslextreme.com wrote:

> On Mon, Sep 19, 2011 at 1:07 PM, ralph.goers @dslextreme.com <ralph.goers@dslextreme.com>
> On Mon, Sep 19, 2011 at 10:07 AM, John Vasileff <john.lists@gmail.com> wrote:
> What do you think about an optional LazyRenderMessage interface (I'm sure there is a
better name for this) that could be used by Message types that have expensive constructers?
> interface LazyRenderMessage {
>   void render();
> }
> The logger would call render() immediately after checking isEnabled for level and marker.
 So, this should not affect serialization - the object will either be fully constructed or
discarded right away.
> This would allow ThreadDumpMessage Thread.getAllStackTraces() work to be avoided unless
logging will actually occur (or is likely to occur in the case of complex filters).
> The benefit of course is that trace(THREAD_DUMP_MARKER, new ThreadDumpMessage()) could
be left in production code without if isTraceEnabled(...) { ... }, and with very little overhead
- creating a short lived object that does nothing in the constructor is pretty cheap these
> This would also help for Message types like ParameterizedMessage to avoid parseArguments(arguments)
when they are created by application code.
> I see some merit in this idea. But you are right, it really needs a better name.
> One other point, though, is that there should always be a constructor that allows immediate
rendering. I could easily see the ThreadDumpMessage being used for other purposes and never
being passed to a logger. For example, I could create two ThreadDumpMessages at slightly different
points in time and then only print the differences between them.
> Ralph 

Good point.

new ThreadDumpMessage().render();

would work if documented in the javadocs for the constructor.  But I would hate to make things
too complicated to bail out those too lazy to check isEnabled.  I don't have a strong opinion
either way on whether this complicates things too much.  Maybe those that need to call render()
will also pick up on the fact, and those that don't, don't need to.  Not sure.

As far as naming goes - I suppose it would take some effort to come up with something worse!
 I have no good ideas.

View raw message