fix: Pattern Layout throwable use Throwable.toString() #4033
+34
−8
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Context
Issue #4019 reports that Pattern Layout no longer preserves custom
Throwable.toString()output after upgrading from 2.24.3 to 2.25.x.The official docs for the
exceptionconverter state that the default behavior (no options) should matchThrowable#printStackTrace(), which relies onThrowable.toString()for the header line.Suspected change: PR #2691
PR #2691 (commit
b55c4d3fa2- "Consolidate stack trace rendering in Pattern Layout") introduced a new renderer pipeline:ThrowableStackTraceRenderer(and extended/inverted variants) to manually render stack traces.ThrowablePatternConverterto delegate to the new renderer instead of callingThrowable#printStackTrace()directly.What changed in rendering behavior
Before PR #2691 (e.g., tag
rel/2.24.3):ThrowablePatternConverterusedThrowable#printStackTrace()directly (either into aStringWriteror aStringBuilderWriter).Throwable.toString().toString()orprintStackTrace()would be reflected in Pattern Layout output.After PR #2691:
ThrowableStackTraceRendererwhich builds the header line manually.ThrowableStackTraceRenderer.renderThrowableMessage(...), the header was constructed as:throwable.getClass().getName()+": " + throwable.getLocalizedMessage()Throwable.toString()entirely.Why that causes #4019
Throwable#printStackTrace()usesThrowable.toString()for its first line.By replacing
printStackTrace()with a manual renderer that usesgetClass().getName()andgetLocalizedMessage(), any customizedtoString()logic is lost.This matches the reporter's symptoms: stack traces remain, but the custom header details disappear.
In short:
%exoutput no longer matchesprintStackTrace()for customtoString()implementations.renderThrowableMessagechanged fromtoString()semantics to explicit class/message concatenation.Test case
I added test case that issue reporter gives.
Related issue: #3623 (Pattern Layout vs. JSON Template Layout)
Issue #3623 reports a mismatch between Pattern Layout (
%ex) and JSON Template Layout (exceptionresolver):Throwable.printStackTrace()forstackTrace.stringified.ThrowableStackTraceRenderer.renderThrowableMessage(...).The JSON Template Layout implementation lives in:
log4j-layout-template-json/src/main/java/org/apache/logging/log4j/layout/template/json/resolver/StackTraceStringResolver.javaSpecifically,
StackTraceStringResolver.resolve(...)callsthrowable.printStackTrace(...)(line ~84), which means its header line always comes fromThrowable.toString().This makes the mismatch visible when exceptions override
toString(). AligningThrowableStackTraceRenderertothrowable.toString()closes both #4019 (regression) and #3623 (layout inconsistency).Checklist
2.xbranch if you are targeting Log4j 2; usemainotherwise./mvnw verifysucceeds (the build instructions)src/changelog/.2.x.xdirectory