[ 
https://issues.apache.org/jira/browse/LOG4J2-3627?focusedWorklogId=924584&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-924584
 ]

ASF GitHub Bot logged work on LOG4J2-3627:
------------------------------------------

                Author: ASF GitHub Bot
            Created on: 05/Jul/24 00:36
            Start Date: 05/Jul/24 00:36
    Worklog Time Spent: 10m 
      Work Description: alan0428a commented on PR #2691:
URL: https://github.com/apache/logging-log4j2/pull/2691#issuecomment-2209669545

   @vy 
   Thanks for your feedback! Actually I am happy we have this careful reveiw 
process, so that we have high standard codes.
   
   Back to the topic, I also agree that this render logic should be in one 
place, since all renderer are doing similar things. But I am not sure if I 
unsderstand what `ThrowableProxy` really is and when it will be created in the 
`LogEvent`? I saw at `xxxThrowablePatternConverter#format()` we do conditions 
checking whether `event.getThrownProxy() is null`. But when will it be null?
   
   For `RootThrowablePatternConverter `, I think the passed in 
[ThrowableProxy](https://github.com/alan0428a/logging-log4j2/blob/42459ed966eaa728757e74d7dcfc0fb1953891ca/log4j-core/src/main/java/org/apache/logging/log4j/core/pattern/RootThrowablePatternConverter.java#L63)
 already has the root cause. Do we need to wrap it like what you mentioned?
   
   From the high level I guess I understand what we want to proceed, and I 
think it's a good resolution. Just there are some small questions may need your 
help to guide me here. Thanks!




Issue Time Tracking
-------------------

    Worklog Id:     (was: 924584)
    Time Spent: 4h 50m  (was: 4h 40m)

> PatternLayout: %xEx{ [ "short" | depth]} not working
> ----------------------------------------------------
>
>                 Key: LOG4J2-3627
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-3627
>             Project: Log4j 2
>          Issue Type: Bug
>          Components: Layouts
>    Affects Versions: 2.11.0, 2.11.1, 2.11.2, 2.12.0, 2.12.1, 2.13.0, 2.13.1, 
> 2.13.2, 2.14.0, 2.13.3, 2.14.1, 2.15.0, 2.16.0, 2.17.1, 2.17.0, 2.12.3, 
> 2.12.2, 2.18.0, 2.12.4, 2.17.2, 2.19.0
>            Reporter: Thorsten Heit
>            Assignee: Volkan Yazici
>            Priority: Minor
>          Time Spent: 4h 50m
>  Remaining Estimate: 0h
>
> According to the documentation the patterns {{{}%xEx{short{}}}} or 
> {{{}%xEx{<num>{}}}} should limit the number of lines of a stack trace that is 
> logged. This doesn't work; instead, the complete stack trace is logged 
> (always!). This is in contrary to the patterns {{%ex}} or {{%rEx}} where this 
> works.
> In commit 9ff63b2e50be754ae394feda2c33d9e64fd0ab3a (2018-01-25) a change was 
> implemented because of LOG4J2-2195 (according to the commit message) that 
> removed the option of limiting the number of lines to output.
> Therefore all versions since 2.11.0 should be affected.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to