[
https://issues.apache.org/jira/browse/LOG4J2-2986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ron Grabowski updated LOG4J2-2986:
----------------------------------
Reporter: Volkan Yazici (was: Ron Grabowski)
> Allow stacktrace pattern converters to specify a starting point to ignore
> redundant framework stack elements
> ------------------------------------------------------------------------------------------------------------
>
> Key: LOG4J2-2986
> URL: https://issues.apache.org/jira/browse/LOG4J2-2986
> Project: Log4j 2
> Issue Type: Improvement
> Components: Layouts
> Reporter: Volkan Yazici
> Priority: Minor
>
> Stack traces from applications in well-known environments can be reduced by
> removing certain bottom components of the stack such as the web container and
> core framework. For example every exception thrown from an application
> running on the fictional Acme framework hosted in Tomcat might produce a
> stack trace like this:
> {code:java}
> at
> example.internal.acme.parser.AcmeMethodInfo$AcmeMethodCallHandler.handleCall(AcmeMethodInfo.java:275)
> at
> example.xml.ws.DefaultWsiInvocationHandler.invoke(DefaultWsiInvocationHandler.java:56)
> at
> example.internal.xml.ws.server.WebservicesServletBase.doPost(WebservicesServletBase.java:500)
> at
> example.internal.xml.ws.server.WebservicesServletBase.doPost(WebservicesServletBase.java:402)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:650)
> at
> example.internal.xml.ws.server.WebservicesServletBase.service(WebservicesServletBase.java:1080)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:731)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
> at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
> at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:505)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:169)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
> at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:956)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:436)
> at
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1078)
> at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:625)
> at
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> When shipping logs to a log aggregation tool the stack trace could be greatly
> reduced (sometimes more than 50%) by omitting the unhelpful duplicate code
> that appears with each exception.
> Its not always possible to catch and re-throw with a reduced stack.
> The exception patterns on this page allow some filtering but I don't want to
> filter out the entire _org.apache_ or _example.internal_ packages. The depth
> parameter seems to start from the top:
> [https://logging.apache.org/log4j/log4j-2.0/manual/layouts.html]
> {code:java}
> rException["none"|"short"|"full"|depth],[filters(packages)}
> {code}
> I briefly scanned the code and couldn't tell if depth supported negative
> numbers. A negative depth could indicate how many lines from the bottom
> should be skipped. From the example above the value would be "depth=-27". A
> alternate (better?) way to express a starting point would be to list what to
> start with. This example removes the web container noise and starts the stack
> trace closer to meaningful code:
> {code}
> startWith=javax.servlet.http.HttpServlet.service
> {code}
> This syntax expresses a slightly more accurate starting point and allows for
> more than one starting point:
> {code}
> startWith=example.internal.acme.parser.AcmeMethodInfo$AcmeMethodCallHandler.handleCall,javax.servlet.http.HttpServlet.service
> {code}
> Another example of the syntax:
> {code:xml}
> <properties>
> <property
> name="startWith">example.internal.acme.parser.AcmeMethodInfo$AcmeMethodCallHandler.handleCall,javax.servlet.http.HttpServlet.service</property>
> </properties>
> <PatternLayout pattern="%m%xEx{startWith(${startWith})}%n"/>
> {code}
> I don't know if this should be implemented with simple string manipulation
> (regex, substring, etc) or actually inspecting each StackTraceElement.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
