[JIRA] Created: (LBCLASSIC-217) Exception stack trace printing starting from root cause
Exception stack trace printing starting from root cause ------------------------------------------------------- Key: LBCLASSIC-217 URL: http://jira.qos.ch/browse/LBCLASSIC-217 Project: logback-classic Issue Type: New Feature Affects Versions: 0.9.22 Reporter: Tomasz Nurkiewicz Assignee: Logback dev list A typical exception in multi-tier application looks similar to this: com.acme.BusinessException: Can't process request at ... at ... Caused by: com.acme.dao.PersistenceException: Can't access database at ... at ... ... 49 common frames omitted Caused by: org.springframework.jdbc.datasource.lookup.DataSourceLookupFailureException: Unable to locate datasource at ... at ... ... 65 common frames omitted Caused by: java.net.UnknownHostException: Unknown host localhostt at ... at ... ... 84 common frames omitted The deeper exception, the more specific information it gives. Typically the last "Caused by" is the most interesting one. So it seems like reversing the order in which the exceptions are thrown (from most specific to consecutive, less specific wrappers) might be more intuitive: java.net.UnknownHostException: Unknown host localhostt at ... at ... Wrapped by: org.springframework.jdbc.datasource.lookup.DataSourceLookupFailureException: Unable to connect to the database at ... at ... Wrapped by: com.acme.dao.PersistenceException: Can't access database at ... at ... Wrapped by: com.acme.BusinessException: Can't process request at ... at ... It is not only easier to read and follow (business exception is interesting for the end user while the most precise, technical information is for developers and system administrators - so it should be easily accessible in the logs), but also the stack trace isn't mixed. You can read stack frames in exactly the same order as they were executed, no need to jump from one stack trace line to another (see attachment from the real application). This also means that the beginning of the thread is always at the bottom and the line that caused the very first exception - at the top. (look at the attached real exception) I already implemented this feature by adding RootCauseFirstThrowableProxyConverter extending ch.qos.logback.classic.pattern.ExtendedThrowableProxyConverter. It is turned on by appending "%rEx" to the encoder pattern. If you like this feature, I will push the changes (just few classes have changed) into my GitHub fork. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCLASSIC-217?page=com.atlassian.jira.plugin.syste... ] Tomasz Nurkiewicz updated LBCLASSIC-217: ---------------------------------------- Attachment: wrapped_by_stack_trace.txt
Exception stack trace printing starting from root cause -------------------------------------------------------
Key: LBCLASSIC-217 URL: http://jira.qos.ch/browse/LBCLASSIC-217 Project: logback-classic Issue Type: New Feature Affects Versions: 0.9.22 Reporter: Tomasz Nurkiewicz Assignee: Logback dev list Attachments: wrapped_by_stack_trace.txt
A typical exception in multi-tier application looks similar to this: com.acme.BusinessException: Can't process request at ... at ... Caused by: com.acme.dao.PersistenceException: Can't access database at ... at ... ... 49 common frames omitted Caused by: org.springframework.jdbc.datasource.lookup.DataSourceLookupFailureException: Unable to locate datasource at ... at ... ... 65 common frames omitted Caused by: java.net.UnknownHostException: Unknown host localhostt at ... at ... ... 84 common frames omitted The deeper exception, the more specific information it gives. Typically the last "Caused by" is the most interesting one. So it seems like reversing the order in which the exceptions are thrown (from most specific to consecutive, less specific wrappers) might be more intuitive: java.net.UnknownHostException: Unknown host localhostt at ... at ... Wrapped by: org.springframework.jdbc.datasource.lookup.DataSourceLookupFailureException: Unable to connect to the database at ... at ... Wrapped by: com.acme.dao.PersistenceException: Can't access database at ... at ... Wrapped by: com.acme.BusinessException: Can't process request at ... at ... It is not only easier to read and follow (business exception is interesting for the end user while the most precise, technical information is for developers and system administrators - so it should be easily accessible in the logs), but also the stack trace isn't mixed. You can read stack frames in exactly the same order as they were executed, no need to jump from one stack trace line to another (see attachment from the real application). This also means that the beginning of the thread is always at the bottom and the line that caused the very first exception - at the top. (look at the attached real exception) I already implemented this feature by adding RootCauseFirstThrowableProxyConverter extending ch.qos.logback.classic.pattern.ExtendedThrowableProxyConverter. It is turned on by appending "%rEx" to the encoder pattern. If you like this feature, I will push the changes (just few classes have changed) into my GitHub fork.
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCLASSIC-217?page=com.atlassian.jira.plugin.syste... ] Tomasz Nurkiewicz commented on LBCLASSIC-217: --------------------------------------------- I pushed rough implementation of this feature, including some smoke unit tests: http://github.com/nurkiewicz/logback/commit/679fcda1a4a3e67fcb2604e47c7fa0de... http://github.com/nurkiewicz/logback/commit/869b85c1362ba5e60d53e92d1480609d...
Exception stack trace printing starting from root cause -------------------------------------------------------
Key: LBCLASSIC-217 URL: http://jira.qos.ch/browse/LBCLASSIC-217 Project: logback-classic Issue Type: New Feature Affects Versions: 0.9.22 Reporter: Tomasz Nurkiewicz Assignee: Logback dev list Attachments: wrapped_by_stack_trace.txt
A typical exception in multi-tier application looks similar to this: com.acme.BusinessException: Can't process request at ... at ... Caused by: com.acme.dao.PersistenceException: Can't access database at ... at ... ... 49 common frames omitted Caused by: org.springframework.jdbc.datasource.lookup.DataSourceLookupFailureException: Unable to locate datasource at ... at ... ... 65 common frames omitted Caused by: java.net.UnknownHostException: Unknown host localhostt at ... at ... ... 84 common frames omitted The deeper exception, the more specific information it gives. Typically the last "Caused by" is the most interesting one. So it seems like reversing the order in which the exceptions are thrown (from most specific to consecutive, less specific wrappers) might be more intuitive: java.net.UnknownHostException: Unknown host localhostt at ... at ... Wrapped by: org.springframework.jdbc.datasource.lookup.DataSourceLookupFailureException: Unable to connect to the database at ... at ... Wrapped by: com.acme.dao.PersistenceException: Can't access database at ... at ... Wrapped by: com.acme.BusinessException: Can't process request at ... at ... It is not only easier to read and follow (business exception is interesting for the end user while the most precise, technical information is for developers and system administrators - so it should be easily accessible in the logs), but also the stack trace isn't mixed. You can read stack frames in exactly the same order as they were executed, no need to jump from one stack trace line to another (see attachment from the real application). This also means that the beginning of the thread is always at the bottom and the line that caused the very first exception - at the top. (look at the attached real exception) I already implemented this feature by adding RootCauseFirstThrowableProxyConverter extending ch.qos.logback.classic.pattern.ExtendedThrowableProxyConverter. It is turned on by appending "%rEx" to the encoder pattern. If you like this feature, I will push the changes (just few classes have changed) into my GitHub fork.
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCLASSIC-217?page=com.atlassian.jira.plugin.syste... ] Tomasz Nurkiewicz commented on LBCLASSIC-217: --------------------------------------------- Any news on this issue?
Exception stack trace printing starting from root cause -------------------------------------------------------
Key: LBCLASSIC-217 URL: http://jira.qos.ch/browse/LBCLASSIC-217 Project: logback-classic Issue Type: New Feature Affects Versions: 0.9.22 Reporter: Tomasz Nurkiewicz Assignee: Logback dev list Attachments: wrapped_by_stack_trace.txt
A typical exception in multi-tier application looks similar to this: com.acme.BusinessException: Can't process request at ... at ... Caused by: com.acme.dao.PersistenceException: Can't access database at ... at ... ... 49 common frames omitted Caused by: org.springframework.jdbc.datasource.lookup.DataSourceLookupFailureException: Unable to locate datasource at ... at ... ... 65 common frames omitted Caused by: java.net.UnknownHostException: Unknown host localhostt at ... at ... ... 84 common frames omitted The deeper exception, the more specific information it gives. Typically the last "Caused by" is the most interesting one. So it seems like reversing the order in which the exceptions are thrown (from most specific to consecutive, less specific wrappers) might be more intuitive: java.net.UnknownHostException: Unknown host localhostt at ... at ... Wrapped by: org.springframework.jdbc.datasource.lookup.DataSourceLookupFailureException: Unable to connect to the database at ... at ... Wrapped by: com.acme.dao.PersistenceException: Can't access database at ... at ... Wrapped by: com.acme.BusinessException: Can't process request at ... at ... It is not only easier to read and follow (business exception is interesting for the end user while the most precise, technical information is for developers and system administrators - so it should be easily accessible in the logs), but also the stack trace isn't mixed. You can read stack frames in exactly the same order as they were executed, no need to jump from one stack trace line to another (see attachment from the real application). This also means that the beginning of the thread is always at the bottom and the line that caused the very first exception - at the top. (look at the attached real exception) I already implemented this feature by adding RootCauseFirstThrowableProxyConverter extending ch.qos.logback.classic.pattern.ExtendedThrowableProxyConverter. It is turned on by appending "%rEx" to the encoder pattern. If you like this feature, I will push the changes (just few classes have changed) into my GitHub fork.
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCLASSIC-217?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu commented on LBCLASSIC-217: -------------------------------------- Looks good.
Exception stack trace printing starting from root cause -------------------------------------------------------
Key: LBCLASSIC-217 URL: http://jira.qos.ch/browse/LBCLASSIC-217 Project: logback-classic Issue Type: New Feature Affects Versions: 0.9.22 Reporter: Tomasz Nurkiewicz Assignee: Logback dev list Attachments: wrapped_by_stack_trace.txt
A typical exception in multi-tier application looks similar to this: com.acme.BusinessException: Can't process request at ... at ... Caused by: com.acme.dao.PersistenceException: Can't access database at ... at ... ... 49 common frames omitted Caused by: org.springframework.jdbc.datasource.lookup.DataSourceLookupFailureException: Unable to locate datasource at ... at ... ... 65 common frames omitted Caused by: java.net.UnknownHostException: Unknown host localhostt at ... at ... ... 84 common frames omitted The deeper exception, the more specific information it gives. Typically the last "Caused by" is the most interesting one. So it seems like reversing the order in which the exceptions are thrown (from most specific to consecutive, less specific wrappers) might be more intuitive: java.net.UnknownHostException: Unknown host localhostt at ... at ... Wrapped by: org.springframework.jdbc.datasource.lookup.DataSourceLookupFailureException: Unable to connect to the database at ... at ... Wrapped by: com.acme.dao.PersistenceException: Can't access database at ... at ... Wrapped by: com.acme.BusinessException: Can't process request at ... at ... It is not only easier to read and follow (business exception is interesting for the end user while the most precise, technical information is for developers and system administrators - so it should be easily accessible in the logs), but also the stack trace isn't mixed. You can read stack frames in exactly the same order as they were executed, no need to jump from one stack trace line to another (see attachment from the real application). This also means that the beginning of the thread is always at the bottom and the line that caused the very first exception - at the top. (look at the attached real exception) I already implemented this feature by adding RootCauseFirstThrowableProxyConverter extending ch.qos.logback.classic.pattern.ExtendedThrowableProxyConverter. It is turned on by appending "%rEx" to the encoder pattern. If you like this feature, I will push the changes (just few classes have changed) into my GitHub fork.
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCLASSIC-217?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu commented on LBCLASSIC-217: -------------------------------------- I get 404 on both github links listed above.
Exception stack trace printing starting from root cause -------------------------------------------------------
Key: LBCLASSIC-217 URL: http://jira.qos.ch/browse/LBCLASSIC-217 Project: logback-classic Issue Type: New Feature Affects Versions: 0.9.22 Reporter: Tomasz Nurkiewicz Assignee: Logback dev list Attachments: wrapped_by_stack_trace.txt
A typical exception in multi-tier application looks similar to this: com.acme.BusinessException: Can't process request at ... at ... Caused by: com.acme.dao.PersistenceException: Can't access database at ... at ... ... 49 common frames omitted Caused by: org.springframework.jdbc.datasource.lookup.DataSourceLookupFailureException: Unable to locate datasource at ... at ... ... 65 common frames omitted Caused by: java.net.UnknownHostException: Unknown host localhostt at ... at ... ... 84 common frames omitted The deeper exception, the more specific information it gives. Typically the last "Caused by" is the most interesting one. So it seems like reversing the order in which the exceptions are thrown (from most specific to consecutive, less specific wrappers) might be more intuitive: java.net.UnknownHostException: Unknown host localhostt at ... at ... Wrapped by: org.springframework.jdbc.datasource.lookup.DataSourceLookupFailureException: Unable to connect to the database at ... at ... Wrapped by: com.acme.dao.PersistenceException: Can't access database at ... at ... Wrapped by: com.acme.BusinessException: Can't process request at ... at ... It is not only easier to read and follow (business exception is interesting for the end user while the most precise, technical information is for developers and system administrators - so it should be easily accessible in the logs), but also the stack trace isn't mixed. You can read stack frames in exactly the same order as they were executed, no need to jump from one stack trace line to another (see attachment from the real application). This also means that the beginning of the thread is always at the bottom and the line that caused the very first exception - at the top. (look at the attached real exception) I already implemented this feature by adding RootCauseFirstThrowableProxyConverter extending ch.qos.logback.classic.pattern.ExtendedThrowableProxyConverter. It is turned on by appending "%rEx" to the encoder pattern. If you like this feature, I will push the changes (just few classes have changed) into my GitHub fork.
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCLASSIC-217?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu commented on LBCLASSIC-217: -------------------------------------- Just applied https://github.com/nurkiewicz/logback/commit/a21ed on my repo.
Exception stack trace printing starting from root cause -------------------------------------------------------
Key: LBCLASSIC-217 URL: http://jira.qos.ch/browse/LBCLASSIC-217 Project: logback-classic Issue Type: New Feature Affects Versions: 0.9.22 Reporter: Tomasz Nurkiewicz Assignee: Logback dev list Attachments: wrapped_by_stack_trace.txt
A typical exception in multi-tier application looks similar to this: com.acme.BusinessException: Can't process request at ... at ... Caused by: com.acme.dao.PersistenceException: Can't access database at ... at ... ... 49 common frames omitted Caused by: org.springframework.jdbc.datasource.lookup.DataSourceLookupFailureException: Unable to locate datasource at ... at ... ... 65 common frames omitted Caused by: java.net.UnknownHostException: Unknown host localhostt at ... at ... ... 84 common frames omitted The deeper exception, the more specific information it gives. Typically the last "Caused by" is the most interesting one. So it seems like reversing the order in which the exceptions are thrown (from most specific to consecutive, less specific wrappers) might be more intuitive: java.net.UnknownHostException: Unknown host localhostt at ... at ... Wrapped by: org.springframework.jdbc.datasource.lookup.DataSourceLookupFailureException: Unable to connect to the database at ... at ... Wrapped by: com.acme.dao.PersistenceException: Can't access database at ... at ... Wrapped by: com.acme.BusinessException: Can't process request at ... at ... It is not only easier to read and follow (business exception is interesting for the end user while the most precise, technical information is for developers and system administrators - so it should be easily accessible in the logs), but also the stack trace isn't mixed. You can read stack frames in exactly the same order as they were executed, no need to jump from one stack trace line to another (see attachment from the real application). This also means that the beginning of the thread is always at the bottom and the line that caused the very first exception - at the top. (look at the attached real exception) I already implemented this feature by adding RootCauseFirstThrowableProxyConverter extending ch.qos.logback.classic.pattern.ExtendedThrowableProxyConverter. It is turned on by appending "%rEx" to the encoder pattern. If you like this feature, I will push the changes (just few classes have changed) into my GitHub fork.
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCLASSIC-217?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu resolved LBCLASSIC-217. ---------------------------------- Fix Version/s: 0.9.30 Resolution: Fixed
Exception stack trace printing starting from root cause -------------------------------------------------------
Key: LBCLASSIC-217 URL: http://jira.qos.ch/browse/LBCLASSIC-217 Project: logback-classic Issue Type: New Feature Affects Versions: 0.9.22 Reporter: Tomasz Nurkiewicz Assignee: Logback dev list Fix For: 0.9.30
Attachments: wrapped_by_stack_trace.txt
A typical exception in multi-tier application looks similar to this: com.acme.BusinessException: Can't process request at ... at ... Caused by: com.acme.dao.PersistenceException: Can't access database at ... at ... ... 49 common frames omitted Caused by: org.springframework.jdbc.datasource.lookup.DataSourceLookupFailureException: Unable to locate datasource at ... at ... ... 65 common frames omitted Caused by: java.net.UnknownHostException: Unknown host localhostt at ... at ... ... 84 common frames omitted The deeper exception, the more specific information it gives. Typically the last "Caused by" is the most interesting one. So it seems like reversing the order in which the exceptions are thrown (from most specific to consecutive, less specific wrappers) might be more intuitive: java.net.UnknownHostException: Unknown host localhostt at ... at ... Wrapped by: org.springframework.jdbc.datasource.lookup.DataSourceLookupFailureException: Unable to connect to the database at ... at ... Wrapped by: com.acme.dao.PersistenceException: Can't access database at ... at ... Wrapped by: com.acme.BusinessException: Can't process request at ... at ... It is not only easier to read and follow (business exception is interesting for the end user while the most precise, technical information is for developers and system administrators - so it should be easily accessible in the logs), but also the stack trace isn't mixed. You can read stack frames in exactly the same order as they were executed, no need to jump from one stack trace line to another (see attachment from the real application). This also means that the beginning of the thread is always at the bottom and the line that caused the very first exception - at the top. (look at the attached real exception) I already implemented this feature by adding RootCauseFirstThrowableProxyConverter extending ch.qos.logback.classic.pattern.ExtendedThrowableProxyConverter. It is turned on by appending "%rEx" to the encoder pattern. If you like this feature, I will push the changes (just few classes have changed) into my GitHub fork.
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCLASSIC-217?page=com.atlassian.jira.plugin.syste... ] Tomasz Nurkiewicz commented on LBCLASSIC-217: --------------------------------------------- Thank you for applying this feature! Sorry for broken links, don't know how this happened. I opened a trivial pull request (Correct 0.9.30 version in @since tag: https://github.com/ceki/logback/pull/28). If you care, I also blogged about this feature: http://nurkiewicz.blogspot.com/2011/09/logging-exceptions-root-cause-first.h...
Exception stack trace printing starting from root cause -------------------------------------------------------
Key: LBCLASSIC-217 URL: http://jira.qos.ch/browse/LBCLASSIC-217 Project: logback-classic Issue Type: New Feature Affects Versions: 0.9.22 Reporter: Tomasz Nurkiewicz Assignee: Logback dev list Fix For: 0.9.30
Attachments: wrapped_by_stack_trace.txt
A typical exception in multi-tier application looks similar to this: com.acme.BusinessException: Can't process request at ... at ... Caused by: com.acme.dao.PersistenceException: Can't access database at ... at ... ... 49 common frames omitted Caused by: org.springframework.jdbc.datasource.lookup.DataSourceLookupFailureException: Unable to locate datasource at ... at ... ... 65 common frames omitted Caused by: java.net.UnknownHostException: Unknown host localhostt at ... at ... ... 84 common frames omitted The deeper exception, the more specific information it gives. Typically the last "Caused by" is the most interesting one. So it seems like reversing the order in which the exceptions are thrown (from most specific to consecutive, less specific wrappers) might be more intuitive: java.net.UnknownHostException: Unknown host localhostt at ... at ... Wrapped by: org.springframework.jdbc.datasource.lookup.DataSourceLookupFailureException: Unable to connect to the database at ... at ... Wrapped by: com.acme.dao.PersistenceException: Can't access database at ... at ... Wrapped by: com.acme.BusinessException: Can't process request at ... at ... It is not only easier to read and follow (business exception is interesting for the end user while the most precise, technical information is for developers and system administrators - so it should be easily accessible in the logs), but also the stack trace isn't mixed. You can read stack frames in exactly the same order as they were executed, no need to jump from one stack trace line to another (see attachment from the real application). This also means that the beginning of the thread is always at the bottom and the line that caused the very first exception - at the top. (look at the attached real exception) I already implemented this feature by adding RootCauseFirstThrowableProxyConverter extending ch.qos.logback.classic.pattern.ExtendedThrowableProxyConverter. It is turned on by appending "%rEx" to the encoder pattern. If you like this feature, I will push the changes (just few classes have changed) into my GitHub fork.
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
participants (2)
-
Ceki Gulcu (JIRA) -
Tomasz Nurkiewicz (JIRA)