logback

Filtering out selected stack trace frames

Details

  • Type: New Feature New Feature
  • Status: Open Open
  • Priority: Minor Minor
  • Resolution: Unresolved
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: logback-classic
  • Labels:
    None

Description

Many frameworks and libraries like Spring or EJB are introducing hundreds of synthetic method invocations (AOP, dynamic proxies, CGLIB-generated classes, etc.) They are irrelevant for most of the time and only cluttering the stack traces printed by Logback.

It would be nice to have possibility to filter (possibly by providing a set of patterns in logback.xml) each stack trace line and skip selected ones. Similar feature is implemented in some IDEs, see: http://blogs.jetbrains.com/idea/2010/07/console-folding-customization.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Tomasz Nurkiewicz added a comment -

I created a small proof-of-concept: https://github.com/nurkiewicz/logback/tree/LBCLASSIC-325 and wrote a little bit more about the problem: http://nurkiewicz.blogspot.com/2012/03/filtering-irrelevant-stack-trace-lines.html.

Show
Tomasz Nurkiewicz added a comment - I created a small proof-of-concept: https://github.com/nurkiewicz/logback/tree/LBCLASSIC-325 and wrote a little bit more about the problem: http://nurkiewicz.blogspot.com/2012/03/filtering-irrelevant-stack-trace-lines.html .
Hide
Permalink
Nick Spacek added a comment -

I like the idea, but I don't like the thought of cluttering the <pattern> with it. Is there any other way we could place a filter on the text output by the logger?

Show
Nick Spacek added a comment - I like the idea, but I don't like the thought of cluttering the <pattern> with it. Is there any other way we could place a filter on the text output by the logger?
Hide
Permalink
Przemysław Pokrywka added a comment -

Very good idea. One more improvement to it would be an ability to INCLUDE "border" lines from ignored packages.
By border lines I mean the lines adjacent to relevant lines.
They are often useful, as you can see the places, where your code interacts with a framework or gets called by it.

An option to include the border lines would further improve this feature.

Show
Przemysław Pokrywka added a comment - Very good idea. One more improvement to it would be an ability to INCLUDE "border" lines from ignored packages. By border lines I mean the lines adjacent to relevant lines. They are often useful, as you can see the places, where your code interacts with a framework or gets called by it. An option to include the border lines would further improve this feature.
Hide
Permalink
Ceki Gulcu added a comment -

Hi Tomasz,

Thank you for yet another cool contribution to the project. Contrary to folder customizations in IDEA, in the case of logback removed stack trace lines cannot be "unremoved" whereas in IDEA they can be unfolded. There must a way to signal to the user which sort (which package) of lines were removed. Thus, it seems to me that Przemysław's remark about border lines becomes particularly relevant in our context.

As for Nick's remark about cluttering the pattern, we could use properties and re-use the masked packages. For example, we could write

<property name="mask"
value="java.lang.reflect.Method,
org.apache.catalina,
org.springframework.aop,
org.springframework.security,
org.springframework.transaction,
org.springframework.web,
sun.reflect,
net.sf.cglib"/>

<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>%d %level %thread %logger

{1}

| %m%n%rEx{full, ${mask}}</pattern>
</encoder>
....
</appender>

Note that the mask property could be defined in a file as well.

Show
Ceki Gulcu added a comment - Hi Tomasz, Thank you for yet another cool contribution to the project. Contrary to folder customizations in IDEA, in the case of logback removed stack trace lines cannot be "unremoved" whereas in IDEA they can be unfolded. There must a way to signal to the user which sort (which package) of lines were removed. Thus, it seems to me that Przemysław's remark about border lines becomes particularly relevant in our context. As for Nick's remark about cluttering the pattern, we could use properties and re-use the masked packages. For example, we could write <property name="mask" value="java.lang.reflect.Method, org.apache.catalina, org.springframework.aop, org.springframework.security, org.springframework.transaction, org.springframework.web, sun.reflect, net.sf.cglib"/> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <encoder> <pattern>%d %level %thread %logger {1} | %m%n%rEx{full, ${mask}}</pattern> </encoder> .... </appender> Note that the mask property could be defined in a file as well.
Hide
Permalink
Leif Warner added a comment - - edited

This feature is available as an add-on for log4j - http://openutils.sourceforge.net/openutils-log4j/filteredlayout.html
It's been very handy for filtering out all the lines of library code I don't care out in the stacktraces, especially the crazy verbose JRuby stuff.

Show
Leif Warner added a comment - - edited This feature is available as an add-on for log4j - http://openutils.sourceforge.net/openutils-log4j/filteredlayout.html It's been very handy for filtering out all the lines of library code I don't care out in the stacktraces, especially the crazy verbose JRuby stuff.
Hide
Permalink
Alexander Czar added a comment -

Any news on this one?

Show
Alexander Czar added a comment - Any news on this one?
Hide
Permalink
Leandro Aparecido added a comment -

Why is it taking so long to merge this patch? It's getting increasingly difficult to read stacktraces in the java world.

Show
Leandro Aparecido added a comment - Why is it taking so long to merge this patch? It's getting increasingly difficult to read stacktraces in the java world.

People

  • Assignee:
    Logback dev list
    Reporter:
    Tomasz Nurkiewicz
Vote (13)
Watch (13)

Dates

  • Created:
    Updated: