fix(logging): collapse framework stack frames via log4j2 %xEx filters - #36516
Conversation
Stack traces in console and dotcms.log were dominated by framework
plumbing - a single GraphQL data error produced 150+ lines of which
only ~10 were dotCMS frames. Apply log4j2's %xEx{filters(...)} with a
shared stack.filter property so frames from Tomcat/Catalina, servlet,
GraphQL execution, java.util.concurrent, reflection, tuckey and vavr
packages collapse to "... suppressed NN lines". Exception messages,
Caused-by chains and all com.dotcms/com.dotmarketing frames remain
visible.
Note: %ex{filters(...)} is silently ignored by log4j2 (verified on
2.23.1) - only %xEx honors the filters option.
Resolves #36515
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Claude finished @wezell's task in 2m 51s —— View job Code ReviewI reviewed the four changed files against New Issues
Notes (non-blocking)
No correctness bugs found in the happy path; both flags are robustness/consistency items and neither blocks merge. • branch |
…lter
Wrap the pattern and stack-filter properties in ${env:...} lookups with
the existing values as fallback defaults, so operators can tune logging
per environment without replacing the whole config file:
- CMS_LOG4J_MESSAGE_PATTERN (dotcms.log file pattern, docker config)
- CMS_LOG4J_CONSOLE_PATTERN (console pattern)
- CMS_LOG4J_STACK_FILTER (comma-separated packages to collapse)
Defaults live in DEFAULT_* properties because a pattern inlined as an
${env:VAR:-default} default value would terminate early at the first
bare '}' from %d{...}/%xEx{...}.
Resolves #36515
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Define the CMS_LOG4J_* defaults in /srv/35-set-logging-defaults.sh
alongside the other container env defaults, following the pattern of
15-detect-fips-and-set-ssl-engine.sh. The docker log4j2.xml now reads
the env vars directly - safe because that config is only installed by
20-copy-overriden-files.sh, i.e. when the entrypoint ran.
The script composes the full patterns with the filter list embedded:
log4j2 does not resolve ${...} lookups inside values sourced from env
vars (log4shell hardening), so a pattern env var cannot reference the
stack.filter property.
The non-docker webapp config keeps self-contained in-file defaults.
Resolves #36515
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
notmattmonroe
left a comment
notmattmonroe
left a comment
There was a problem hiding this comment.
reviewed for better logging
|
Tick the box to add this pull request to the merge queue (same as
|
4 participants
Proposed Changes
stack.filterproperty listing framework/plumbing packages to both runtime log4j2 configs (webapp default and Docker OVERRIDE, which is what production containers use).%xEx{filters(${stack.filter})}to the Console pattern in both configs and toMESSAGE_PATTERN(used by thedotcms.logRollingFile appender) in the Docker override.Frames from
org.apache.catalina/coyote/tomcat,javax.servlet,org.tuckey,io.vavr,graphql.execution/kickstart/GraphQL,java.util.concurrent,java.lang.Thread,sun.nio.ch,jdk.internal.reflect, andjava.lang.reflectcollapse to a single... suppressed NN linesmarker. Exception messages, fullCaused bychains, and allcom.dotcms/com.dotmarketingframes remain visible. A representative 150-line GraphQL trace renders at ~15 lines.Environment-variable overrides
Operators can tune logging per environment without replacing the config file:
CMS_LOG4J_CONSOLE_PATTERNCMS_LOG4J_MESSAGE_PATTERNdotcms.logfile pattern (Docker config)CMS_LOG4J_STACK_FILTERIn the container, defaults live in a new entrypoint script
/srv/35-set-logging-defaults.sh(same pattern as15-detect-fips-and-set-ssl-engine.shforCMS_SSL_ENGINE); the Docker log4j2.xml reads the env vars directly, which is safe because that config is only installed by20-copy-overriden-files.shwhen the entrypoint ran. The script composes the full patterns with the filter list embedded — log4j2 does not resolve${...}lookups inside values sourced from env vars (log4shell hardening), so a pattern env var cannot reference thestack.filterproperty. The non-docker webapp config keeps self-contained in-file defaults with the same env-var override hooks.Checklist
bom/logging/pom.xml) against both edited config files with exceptions thrown throughCompletableFuturechains, reflection, executors, andio.vavr.control.Try— filtered frames collapse, application frames and cause chains stay intact.Before (GraphQL story-block JSON error, abridged — 150+ lines in production):
After:
Note
Testing showed
%ex{filters(...)}is silently ignored by log4j2 — only%xExhonors thefiltersoption. The test configs (dotcms-integration,dotcms-postman,e2e,config/user/logging) all use%ex{filters(...)}, so their frame filtering has never worked; left out of scope here as a one-character follow-up fix.Resolves #36515
🤖 Generated with Claude Code
This PR fixes: #36515