Problem Statement
dotCMS uses log4j2 and runs in Tomcat. When running in a container, only the dotCMS application logs (emitted via log4j2) reach the container log stream (docker logs / kubectl logs). Tomcat's own internal logging via java.util.logging (JULI) — the "catalina" logs such as org.apache.catalina.* and org.apache.coyote.* (connector init, lifecycle, startup errors) — are written to a separate catalina.<date>.log file and do not reliably surface in the container log stream.
This makes container-only failures (connector/SSL/startup/lifecycle problems) hard to debug, since the operator only sees dotCMS app logs and has no easy access to the Tomcat-internal logs.
Root cause: Tomcat's raw java.util.logging stream is not bridged into log4j2. log4j-appserver's TomcatLogger only intercepts the org.apache.juli.logging.Log facade; any code logging directly via java.util.logging falls through to the JULI AsyncFileHandler (separate catalina.<date>.log) plus a ConsoleHandler that does not surface. The log4j-jul bridge jar is absent from the image.
Impact: Observability / debuggability in containerized deployments. No functional/runtime impact.
Steps to Reproduce
- Run the dotCMS Docker image in a container.
- Tail the container logs (
docker logs <container>).
- Observe that dotCMS application logs appear, but Tomcat-internal
org.apache.catalina.* / org.apache.coyote.* (catalina) lines do not.
- Exec into the container and observe a separate
logs/catalina.<date>.log file holding the missing Tomcat-internal logs.
Acceptance Criteria
dotCMS Version
Latest from main branch (container/Docker image).
Severity
Medium - Some functionality impacted
Links
NA
Problem Statement
dotCMS uses log4j2 and runs in Tomcat. When running in a container, only the dotCMS application logs (emitted via log4j2) reach the container log stream (
docker logs/kubectl logs). Tomcat's own internal logging viajava.util.logging(JULI) — the "catalina" logs such asorg.apache.catalina.*andorg.apache.coyote.*(connector init, lifecycle, startup errors) — are written to a separatecatalina.<date>.logfile and do not reliably surface in the container log stream.This makes container-only failures (connector/SSL/startup/lifecycle problems) hard to debug, since the operator only sees dotCMS app logs and has no easy access to the Tomcat-internal logs.
Root cause: Tomcat's raw
java.util.loggingstream is not bridged into log4j2.log4j-appserver'sTomcatLoggeronly intercepts theorg.apache.juli.logging.Logfacade; any code logging directly viajava.util.loggingfalls through to the JULIAsyncFileHandler(separatecatalina.<date>.log) plus aConsoleHandlerthat does not surface. Thelog4j-julbridge jar is absent from the image.Impact: Observability / debuggability in containerized deployments. No functional/runtime impact.
Steps to Reproduce
docker logs <container>).org.apache.catalina.*/org.apache.coyote.*(catalina) lines do not.logs/catalina.<date>.logfile holding the missing Tomcat-internal logs.Acceptance Criteria
docker logs/kubectl logs).dotcms.log, unified with application logs.catalina.<date>.logfile is produced.AccessLogValve) remain a separate file (not routed to console/dotcms.log).dotCMS Version
Latest from
mainbranch (container/Docker image).Severity
Medium - Some functionality impacted
Links
NA