Re: looking for source

[Nicholas Duane]

Great, that explains it.


Thanks,

Nick


From: Ralph Goers 
Sent: Sunday, November 6, 2016 8:14 PM
To: Log4J Users List
Subject: Re: looking for source

Because most people want the exception printed PatternLayout includes the 
ExtendedThrowableConverter by default as the last parameter unless you specify 
%noex. The exception is normally not formatted by the Message.

Ralph

> On Nov 6, 2016, at 4:22 PM, Nicholas Duane  wrote:
>
> My configuration simply has %msg in the pattern layout to output the message. 
>  However, that seems to be outputting the message along with some serialized 
> representation of the exception.  I was looking at the message pattern 
> converter at:
>
>
> https://github.com/apache/logging-log4j2/blob/master/log4j-core/src/main/java/org/apache/logging/log4j/core/pattern/MessagePatternConverter.java
[https://avatars1.githubusercontent.com/u/47359?v=3&s=400]

apache/logging-log4j2
github.com
logging-log4j2 - Mirror of Apache Logging Log4J2


>
>
> which I assume is what formats the string for the %msg pattern.  Is that 
> correct?  I don't see in the code where it's getting the exception info, but 
> I guess it might already be in the Message object.
>
>
> Thanks,
>
> Nick
>
> 
> From: Ralph Goers 
> Sent: Sunday, November 6, 2016 1:38 AM
> To: Log4J Users List
> Subject: Re: looking for source
>
> If you look at PatternLayout you will see a few choices for how the Exception 
> gets formatted. %ex uses printStackTrace to format the Exception, however 
> that is not the default. We extend the stack trace to also include the source 
> of each class (i.e. the jar or class directory) and its version, if it can be 
> determined. Other Layouts may, or may not, format the Exception depending on 
> what they are attempting to do.
>
> To take this further, there are many components that make up the log event - 
> the level, Marker, message (with or without parameters), time, ThreadContext 
> values, logger name, class name, method name, line number and the exception. 
> Each of these are discrete values that the Layout can format (or not) as it 
> chooses.
>
> Ralph
>
>> On Nov 5, 2016, at 6:33 PM, Nicholas Duane  wrote:
>>
>> Thanks.  I have no problem doing that.  Just wondering what needs to be done 
>> and how?  I guess I was hoping that the logging framework, eg. log4j, 
>> handled combining the message and the exception such that no matter what 
>> appender/layout you used you'd get consistent results.  Sounds like that's 
>> not the case.  So are you saying I need to combine the message and the 
>> exception myself within our appender/layout?
>>
>>
>> From the code I included below you can see we're doing:
>>
>>
>> String message = logEvent.getMessage().getFormattedMessage();
>>
>>
>> to get the event's message.  Are you saying we should be doing something 
>> like this:
>>
>>
>> StringWriter sw = new StringWriter();
>> logEvent.getThrown().printStackTrace(new PrintWriter(sw));
>> String exceptionAsString = sw.toString();
>> String message = logEvent.getMessage().getFormattedMessage() + "\n" + 
>> exceptionAsString;
>>
>>
>> Thanks,
>>
>> Nick
>>
>> 
>> From: Remko Popma mailto:remko.po...@gmail.com>>
>> Sent: Saturday, November 5, 2016 9:16 PM
>> To: Log4J Users List
>> Subject: Re: looking for source
>>
>> The point is that in a custom layout/appender you should get the throwable 
>> from the LogEvent, not from the Message. That is the design that all Layouts 
>> and Appenders follow and should follow.
>>
>> The Message object passed to the Layout may no longer have the Throwable.
>>
>> Sent from my iPhone
>>
>>> On 6 Nov 2016, at 10:01, Nicholas Duane  wrote:
>>>
>>> Thanks for the info.  Unfortunately I'm not following.  If someone can 
>>> point me to the source in question I will certainly look it over.  My 
>>> sample outputs the message (%msg) and when the method logger.error(String 
>>> message, Throwable t) is called it seems some code is combining the 
>>> supplied string message with the exception message and stack trace.  Just 
>>> wondering what code is doing that as I'm told someone using our 
>>> appender/layout is not seeing the exception.
>>>
>>>
>>> Thanks,
>>>
>>> Nick
>>>
>>> 
>>> From: Remko Popma 
>>> Sent: Friday, November 4, 2016 9:58 PM
>>> To: Log4J Users List
>>> Subject: Re: looking for source
>>>
>>> The Throwable is initially captured in the Message (usually 
>>> ParameterizedMessage or its garbage-free equivalent), but is later 
>>> transferred to the LogEvent.
>>>
>>> By the time the LogEvent reaches the Layout, the Message instance may b

Re: looking for source

[Ralph Goers]

Because most people want the exception printed PatternLayout includes the 
ExtendedThrowableConverter by default as the last parameter unless you specify 
%noex. The exception is normally not formatted by the Message.

Ralph

> On Nov 6, 2016, at 4:22 PM, Nicholas Duane  wrote:
> 
> My configuration simply has %msg in the pattern layout to output the message. 
>  However, that seems to be outputting the message along with some serialized 
> representation of the exception.  I was looking at the message pattern 
> converter at:
> 
> 
> https://github.com/apache/logging-log4j2/blob/master/log4j-core/src/main/java/org/apache/logging/log4j/core/pattern/MessagePatternConverter.java
> 
> 
> which I assume is what formats the string for the %msg pattern.  Is that 
> correct?  I don't see in the code where it's getting the exception info, but 
> I guess it might already be in the Message object.
> 
> 
> Thanks,
> 
> Nick
> 
> 
> From: Ralph Goers 
> Sent: Sunday, November 6, 2016 1:38 AM
> To: Log4J Users List
> Subject: Re: looking for source
> 
> If you look at PatternLayout you will see a few choices for how the Exception 
> gets formatted. %ex uses printStackTrace to format the Exception, however 
> that is not the default. We extend the stack trace to also include the source 
> of each class (i.e. the jar or class directory) and its version, if it can be 
> determined. Other Layouts may, or may not, format the Exception depending on 
> what they are attempting to do.
> 
> To take this further, there are many components that make up the log event - 
> the level, Marker, message (with or without parameters), time, ThreadContext 
> values, logger name, class name, method name, line number and the exception. 
> Each of these are discrete values that the Layout can format (or not) as it 
> chooses.
> 
> Ralph
> 
>> On Nov 5, 2016, at 6:33 PM, Nicholas Duane  wrote:
>> 
>> Thanks.  I have no problem doing that.  Just wondering what needs to be done 
>> and how?  I guess I was hoping that the logging framework, eg. log4j, 
>> handled combining the message and the exception such that no matter what 
>> appender/layout you used you'd get consistent results.  Sounds like that's 
>> not the case.  So are you saying I need to combine the message and the 
>> exception myself within our appender/layout?
>> 
>> 
>> From the code I included below you can see we're doing:
>> 
>> 
>> String message = logEvent.getMessage().getFormattedMessage();
>> 
>> 
>> to get the event's message.  Are you saying we should be doing something 
>> like this:
>> 
>> 
>> StringWriter sw = new StringWriter();
>> logEvent.getThrown().printStackTrace(new PrintWriter(sw));
>> String exceptionAsString = sw.toString();
>> String message = logEvent.getMessage().getFormattedMessage() + "\n" + 
>> exceptionAsString;
>> 
>> 
>> Thanks,
>> 
>> Nick
>> 
>> 
>> From: Remko Popma mailto:remko.po...@gmail.com>>
>> Sent: Saturday, November 5, 2016 9:16 PM
>> To: Log4J Users List
>> Subject: Re: looking for source
>> 
>> The point is that in a custom layout/appender you should get the throwable 
>> from the LogEvent, not from the Message. That is the design that all Layouts 
>> and Appenders follow and should follow.
>> 
>> The Message object passed to the Layout may no longer have the Throwable.
>> 
>> Sent from my iPhone
>> 
>>> On 6 Nov 2016, at 10:01, Nicholas Duane  wrote:
>>> 
>>> Thanks for the info.  Unfortunately I'm not following.  If someone can 
>>> point me to the source in question I will certainly look it over.  My 
>>> sample outputs the message (%msg) and when the method logger.error(String 
>>> message, Throwable t) is called it seems some code is combining the 
>>> supplied string message with the exception message and stack trace.  Just 
>>> wondering what code is doing that as I'm told someone using our 
>>> appender/layout is not seeing the exception.
>>> 
>>> 
>>> Thanks,
>>> 
>>> Nick
>>> 
>>> 
>>> From: Remko Popma 
>>> Sent: Friday, November 4, 2016 9:58 PM
>>> To: Log4J Users List
>>> Subject: Re: looking for source
>>> 
>>> The Throwable is initially captured in the Message (usually 
>>> ParameterizedMessage or its garbage-free equivalent), but is later 
>>> transferred to the LogEvent.
>>> 
>>> By the time the LogEvent reaches the Layout, the Message instance may be a 
>>> different Object than the one that originally held the Throwable.
>>> 
>>> The Layout should get the Throwable from the LogEvent, not from the Message.
>>> 
>>> Remko
>>> 
>>> Sent from my iPhone
>>> 
 On 5 Nov 2016, at 7:50,Nicholas Duane  wrote:
 
 Thanks for the replies.  Let me ask a more pointed question now as 
 rummaging through the source will probably take me hours.  I'm curious 
 about the overloads with the throwable, for instance:
 
 
 logger.error("some message", );
 
 
 What's the expected behavior?  Meaning, what

Re: looking for source

[Nicholas Duane]

My configuration simply has %msg in the pattern layout to output the message.  
However, that seems to be outputting the message along with some serialized 
representation of the exception.  I was looking at the message pattern 
converter at:


https://github.com/apache/logging-log4j2/blob/master/log4j-core/src/main/java/org/apache/logging/log4j/core/pattern/MessagePatternConverter.java


which I assume is what formats the string for the %msg pattern.  Is that 
correct?  I don't see in the code where it's getting the exception info, but I 
guess it might already be in the Message object.


Thanks,

Nick


From: Ralph Goers 
Sent: Sunday, November 6, 2016 1:38 AM
To: Log4J Users List
Subject: Re: looking for source

If you look at PatternLayout you will see a few choices for how the Exception 
gets formatted. %ex uses printStackTrace to format the Exception, however that 
is not the default. We extend the stack trace to also include the source of 
each class (i.e. the jar or class directory) and its version, if it can be 
determined. Other Layouts may, or may not, format the Exception depending on 
what they are attempting to do.

To take this further, there are many components that make up the log event - 
the level, Marker, message (with or without parameters), time, ThreadContext 
values, logger name, class name, method name, line number and the exception. 
Each of these are discrete values that the Layout can format (or not) as it 
chooses.

Ralph

> On Nov 5, 2016, at 6:33 PM, Nicholas Duane  wrote:
>
> Thanks.  I have no problem doing that.  Just wondering what needs to be done 
> and how?  I guess I was hoping that the logging framework, eg. log4j, handled 
> combining the message and the exception such that no matter what 
> appender/layout you used you'd get consistent results.  Sounds like that's 
> not the case.  So are you saying I need to combine the message and the 
> exception myself within our appender/layout?
>
>
> From the code I included below you can see we're doing:
>
>
> String message = logEvent.getMessage().getFormattedMessage();
>
>
> to get the event's message.  Are you saying we should be doing something like 
> this:
>
>
> StringWriter sw = new StringWriter();
> logEvent.getThrown().printStackTrace(new PrintWriter(sw));
> String exceptionAsString = sw.toString();
> String message = logEvent.getMessage().getFormattedMessage() + "\n" + 
> exceptionAsString;
>
>
> Thanks,
>
> Nick
>
> 
> From: Remko Popma mailto:remko.po...@gmail.com>>
> Sent: Saturday, November 5, 2016 9:16 PM
> To: Log4J Users List
> Subject: Re: looking for source
>
> The point is that in a custom layout/appender you should get the throwable 
> from the LogEvent, not from the Message. That is the design that all Layouts 
> and Appenders follow and should follow.
>
> The Message object passed to the Layout may no longer have the Throwable.
>
> Sent from my iPhone
>
>> On 6 Nov 2016, at 10:01, Nicholas Duane  wrote:
>>
>> Thanks for the info.  Unfortunately I'm not following.  If someone can point 
>> me to the source in question I will certainly look it over.  My sample 
>> outputs the message (%msg) and when the method logger.error(String message, 
>> Throwable t) is called it seems some code is combining the supplied string 
>> message with the exception message and stack trace.  Just wondering what 
>> code is doing that as I'm told someone using our appender/layout is not 
>> seeing the exception.
>>
>>
>> Thanks,
>>
>> Nick
>>
>> 
>> From: Remko Popma 
>> Sent: Friday, November 4, 2016 9:58 PM
>> To: Log4J Users List
>> Subject: Re: looking for source
>>
>> The Throwable is initially captured in the Message (usually 
>> ParameterizedMessage or its garbage-free equivalent), but is later 
>> transferred to the LogEvent.
>>
>> By the time the LogEvent reaches the Layout, the Message instance may be a 
>> different Object than the one that originally held the Throwable.
>>
>> The Layout should get the Throwable from the LogEvent, not from the Message.
>>
>> Remko
>>
>> Sent from my iPhone
>>
>>> On 5 Nov 2016, at 7:50,Nicholas Duane  wrote:
>>>
>>> Thanks for the replies.  Let me ask a more pointed question now as 
>>> rummaging through the source will probably take me hours.  I'm curious 
>>> about the overloads with the throwable, for instance:
>>>
>>>
>>> logger.error("some message", );
>>>
>>>
>>> What's the expected behavior?  Meaning, what is the logging framework going 
>>> to do with the message and the exception?  I know the message is usually 
>>> output via the message property in the pattern layout.  But what happens 
>>> with the throwable?  Is there some code responsible for constructing a 
>>> message which combines the supplied message with the throwable exception 
>>> message and callstack?
>>>
>>>
>>> I wrote the following simple java sample:
>>>
>>>
>>> import org.apache.logging.log4j.Logger;
>>> imp