You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Gary Gregory <ga...@gmail.com> on 2018/01/25 18:11:33 UTC
[log4j][LOG4J2-2195] PatternLayout, %exception, separator, and suffix
Hi All:
I am looking at https://issues.apache.org/jira/browse/LOG4J2-2195
Looking at our documentation for PatternLayout, the way I interpret
"suffix" is that it is a string printed _after_ the stack trace is printed
out. Makes sense, handy. The "separator" attribute is supposed to represent
the separation between each element of a stack trace and is set to the
system line separator by default. This does not work in certain
combinations, hence the ticket.
What the code currently does and tests is that the suffix is printed at the
end of each stack trace element. By default is suffix is an empty string.
You cannot print a single string at the end of a stack trace.
What I propose is:
- suffix only prints at the end of the stack trace
- separator prints at the end of each stack trace element
Thoughts?
Gary
Re: [log4j][LOG4J2-2195] PatternLayout, %exception, separator, and suffix
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Jan 25, 2018 at 11:56 AM, Gary Gregory <ga...@gmail.com>
wrote:
> On Thu, Jan 25, 2018 at 11:46 AM, Ralph Goers <ra...@dslextreme.com>
> wrote:
>
>>
>> > On Jan 25, 2018, at 11:11 AM, Gary Gregory <ga...@gmail.com>
>> wrote:
>> >
>> > Hi All:
>> >
>> > I am looking at https://issues.apache.org/jira/browse/LOG4J2-2195
>> >
>> > Looking at our documentation for PatternLayout, the way I interpret
>> > "suffix" is that it is a string printed _after_ the stack trace is
>> printed
>> > out. Makes sense, handy. The "separator" attribute is supposed to
>> represent
>> > the separation between each element of a stack trace and is set to the
>> > system line separator by default. This does not work in certain
>> > combinations, hence the ticket.
>> >
>> > What the code currently does and tests is that the suffix is printed at
>> the
>> > end of each stack trace element. By default is suffix is an empty
>> string.
>> >
>> > You cannot print a single string at the end of a stack trace.
>> >
>> > What I propose is:
>> > - suffix only prints at the end of the stack trace
>> > - separator prints at the end of each stack trace element
>> >
>> > Thoughts?
>>
>> This feature was added on last march. I can’t tell from the commit log
>> what the Jira issue number was but the commit message specifically says it
>> adds the suffix to each line. I have no idea what the use case was but what
>> you are proposing would break that so I don’t think modifying the behavior
>> of that is a great idea as it breaks compatibility.
>>
>
> Here it is from the changes.xml:
>
> <action issue="LOG4J2-1843" dev="mattsicker" type="add"
> due-to="Zilong Song">
> Add support for appending common suffix to each line of throwable
> stack trace.
> </action>
>
Also looking at https://issues.apache.org/jira/browse/LOG4J2-1838 it is now
clear that the documentation needs improvement. I'll see about fixing that
and fixing the bug without breaking suffix.
Gary
>
> Gary
>
>
>>
>> Ralph
>>
>>
>>
>
Re: [log4j][LOG4J2-2195] PatternLayout, %exception, separator, and suffix
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Jan 25, 2018 at 11:46 AM, Ralph Goers <ra...@dslextreme.com>
wrote:
>
> > On Jan 25, 2018, at 11:11 AM, Gary Gregory <ga...@gmail.com>
> wrote:
> >
> > Hi All:
> >
> > I am looking at https://issues.apache.org/jira/browse/LOG4J2-2195
> >
> > Looking at our documentation for PatternLayout, the way I interpret
> > "suffix" is that it is a string printed _after_ the stack trace is
> printed
> > out. Makes sense, handy. The "separator" attribute is supposed to
> represent
> > the separation between each element of a stack trace and is set to the
> > system line separator by default. This does not work in certain
> > combinations, hence the ticket.
> >
> > What the code currently does and tests is that the suffix is printed at
> the
> > end of each stack trace element. By default is suffix is an empty string.
> >
> > You cannot print a single string at the end of a stack trace.
> >
> > What I propose is:
> > - suffix only prints at the end of the stack trace
> > - separator prints at the end of each stack trace element
> >
> > Thoughts?
>
> This feature was added on last march. I can’t tell from the commit log
> what the Jira issue number was but the commit message specifically says it
> adds the suffix to each line. I have no idea what the use case was but what
> you are proposing would break that so I don’t think modifying the behavior
> of that is a great idea as it breaks compatibility.
>
Here it is from the changes.xml:
<action issue="LOG4J2-1843" dev="mattsicker" type="add"
due-to="Zilong Song">
Add support for appending common suffix to each line of throwable
stack trace.
</action>
Gary
>
> Ralph
>
>
>
Re: [log4j][LOG4J2-2195] PatternLayout, %exception, separator, and
suffix
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Jan 25, 2018, at 11:11 AM, Gary Gregory <ga...@gmail.com> wrote:
>
> Hi All:
>
> I am looking at https://issues.apache.org/jira/browse/LOG4J2-2195
>
> Looking at our documentation for PatternLayout, the way I interpret
> "suffix" is that it is a string printed _after_ the stack trace is printed
> out. Makes sense, handy. The "separator" attribute is supposed to represent
> the separation between each element of a stack trace and is set to the
> system line separator by default. This does not work in certain
> combinations, hence the ticket.
>
> What the code currently does and tests is that the suffix is printed at the
> end of each stack trace element. By default is suffix is an empty string.
>
> You cannot print a single string at the end of a stack trace.
>
> What I propose is:
> - suffix only prints at the end of the stack trace
> - separator prints at the end of each stack trace element
>
> Thoughts?
This feature was added on last march. I can’t tell from the commit log what the Jira issue number was but the commit message specifically says it adds the suffix to each line. I have no idea what the use case was but what you are proposing would break that so I don’t think modifying the behavior of that is a great idea as it breaks compatibility.
Ralph