[ http://jira.qos.ch/browse/LBCLASSIC-170?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu commented on LBCLASSIC-170: -------------------------------------- A recent commit [1] has DBAppender output the exception class and message as the first line. Root causes are also output recursively. The table schema remains unchanged. Admittedly, placing each stack trace line in a new row in string form (without explicit columns for the class, file and line number) is a little silly. Instead of aggregating the stack trace into a single line, a separate column for the various exception fields would have been better because it would allow searches based on exception classes/messages or stack traces. IMO, the nicest approach table structure would be akin to: CREATE TABLE logging_event_exception ( event_id INT NOT NULL, i SMALLINT NOT NULL, -- 0 for the topmost exception, incremented by one for each nested exception exception_class VARCHAR(256) NOT NULL, exception_msg VARCHAR(1024), stack_trace VARCHAR(16384) PRIMARY KEY(event_id, i), FOREIGN KEY (event_id) REFERENCES logging_event(event_id)); where i would be incremented by one for each 'root cause'. WDYT? [1] http://github.com/ceki/logback/commit/130277bce0

DbAppender discards all exception' details ------------------------------------------

Key: LBCLASSIC-170 URL: http://jira.qos.ch/browse/LBCLASSIC-170 Project: logback-classic Issue Type: Bug Components: appender Affects Versions: 0.9.18 Reporter: Tomasz Nurkiewicz Assignee: Ceki Gulcu Fix For: 0.9.19

DbAppender uses a single table logging_event_exception to persist stack traces, inserting one row per each stack frame. Also, each row has its parent event id. Unfortunately this approach loses a lot of exception details, making it unable to fully recreate ILoggingEvent instance that was logged by the DbAppender. List of attributes that are missing: * exception message * exception class name * exception root cause Also logging_event_exception saves the result of ch.qos.logback.classic.spi.StackTraceElementProxy#toString (which refers to java.lang.StackTraceElement#toString) instead of saving each element of java.lang.StackTraceElement separately. Now, in order to recreate StackTraceElement instance one must parse (probably using regular expression) string saved in trace_line attribute. My suggestion would be to create two tables: * logging_event_throwable with columns: message, class_name and cause foreign key referencing other logging_event_throwable instance * logging_event_stack_frame with columns: class_name, method, file, line and a foreign key referencing logging_event_throwable + indexing column Also logging_event would have a optional foreign key to logging_event_throwable. This modifications in database schema would allow to fully recreate ILoggingEvent. For backward compatibility ch.qos.logback.classic.db.DBAppender should remain untouched. The idea is to subclass it and override ch.qos.logback.classic.db.DBAppender#insertThrowable.

-- 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-170?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu edited comment on LBCLASSIC-170 at 3/22/10 11:19 PM: ---------------------------------------------------------------- A recent commit [1] has DBAppender output the exception class and message as the first line. Root causes are also output recursively. The table schema remains unchanged. Admittedly, placing each stack trace line in a new row in string form (without explicit columns for the class, file and line number) is a little silly. Instead of aggregating the stack trace into a single line, a separate column for the various exception fields would have been better because it would allow searches based on exception classes/messages or stack traces. IMO, the nicest approach table structure would be akin to: CREATE TABLE logging_event_exception ( event_id INT NOT NULL, i SMALLINT NOT NULL, -- 0 for the topmost exception, incremented by one for each nested exception exception_class VARCHAR(256) NOT NULL, exception_msg VARCHAR(1024), stack_trace VARCHAR(16384) PRIMARY KEY(event_id, i), FOREIGN KEY (event_id) REFERENCES logging_event(event_id)); where i would be incremented by one for each 'root cause'. If in addition, the LOGGING_EVENT table contained the total number of nested exception, it would be rather easy to retrieve the original exception plus its root causes. WDYT? [1] http://github.com/ceki/logback/commit/130277bce0 was (Author: noreply.ceki@qos.ch): A recent commit [1] has DBAppender output the exception class and message as the first line. Root causes are also output recursively. The table schema remains unchanged. Admittedly, placing each stack trace line in a new row in string form (without explicit columns for the class, file and line number) is a little silly. Instead of aggregating the stack trace into a single line, a separate column for the various exception fields would have been better because it would allow searches based on exception classes/messages or stack traces. IMO, the nicest approach table structure would be akin to: CREATE TABLE logging_event_exception ( event_id INT NOT NULL, i SMALLINT NOT NULL, -- 0 for the topmost exception, incremented by one for each nested exception exception_class VARCHAR(256) NOT NULL, exception_msg VARCHAR(1024), stack_trace VARCHAR(16384) PRIMARY KEY(event_id, i), FOREIGN KEY (event_id) REFERENCES logging_event(event_id)); where i would be incremented by one for each 'root cause'. WDYT? [1] http://github.com/ceki/logback/commit/130277bce0

DbAppender discards all exception' details ------------------------------------------

Key: LBCLASSIC-170 URL: http://jira.qos.ch/browse/LBCLASSIC-170 Project: logback-classic Issue Type: Bug Components: appender Affects Versions: 0.9.18 Reporter: Tomasz Nurkiewicz Assignee: Ceki Gulcu Fix For: 0.9.19

DbAppender uses a single table logging_event_exception to persist stack traces, inserting one row per each stack frame. Also, each row has its parent event id. Unfortunately this approach loses a lot of exception details, making it unable to fully recreate ILoggingEvent instance that was logged by the DbAppender. List of attributes that are missing: * exception message * exception class name * exception root cause Also logging_event_exception saves the result of ch.qos.logback.classic.spi.StackTraceElementProxy#toString (which refers to java.lang.StackTraceElement#toString) instead of saving each element of java.lang.StackTraceElement separately. Now, in order to recreate StackTraceElement instance one must parse (probably using regular expression) string saved in trace_line attribute. My suggestion would be to create two tables: * logging_event_throwable with columns: message, class_name and cause foreign key referencing other logging_event_throwable instance * logging_event_stack_frame with columns: class_name, method, file, line and a foreign key referencing logging_event_throwable + indexing column Also logging_event would have a optional foreign key to logging_event_throwable. This modifications in database schema would allow to fully recreate ILoggingEvent. For backward compatibility ch.qos.logback.classic.db.DBAppender should remain untouched. The idea is to subclass it and override ch.qos.logback.classic.db.DBAppender#insertThrowable.

-- 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