[JIRA] Created: (LBCORE-159) AppenderBase and UnsynchronizedAppenderBsae do not allow exceptions to percolate to the application
AppenderBase and UnsynchronizedAppenderBsae do not allow exceptions to percolate to the application --------------------------------------------------------------------------------------------------- Key: LBCORE-159 URL: http://jira.qos.ch/browse/LBCORE-159 Project: logback-core Issue Type: Improvement Components: Appender Affects Versions: 0.9.24 Environment: All Reporter: Ralph Goers Assignee: Logback dev list When logging some events the application needs to be informed that the publishing of the event failed. Currently, AppenderBase and UnsynchronizedAppenderBase catch and handle all exceptions making it impossible to use any of the out-of-the box Logback appenders in these situations. This is particularly important when performing auditing and sending the events to a database, JMS queue, socket, etc. as the application would want to fail the current operation if it cannot be audited. -- 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/LBCORE-159?page=com.atlassian.jira.plugin.system.i... ] Ralph Goers updated LBCORE-159: ------------------------------- Attachment: exceptionPatch.txt The attached patch allows an Appender to be configured to percolate exceptions to the application.
AppenderBase and UnsynchronizedAppenderBsae do not allow exceptions to percolate to the application ---------------------------------------------------------------------------------------------------
Key: LBCORE-159 URL: http://jira.qos.ch/browse/LBCORE-159 Project: logback-core Issue Type: Improvement Components: Appender Affects Versions: 0.9.24 Environment: All Reporter: Ralph Goers Assignee: Logback dev list Attachments: exceptionPatch.txt
When logging some events the application needs to be informed that the publishing of the event failed. Currently, AppenderBase and UnsynchronizedAppenderBase catch and handle all exceptions making it impossible to use any of the out-of-the box Logback appenders in these situations. This is particularly important when performing auditing and sending the events to a database, JMS queue, socket, etc. as the application would want to fail the current operation if it cannot be audited.
-- 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/LBCORE-159?page=com.atlassian.jira.plugin.system.i... ] Ceki Gulcu reassigned LBCORE-159: --------------------------------- Assignee: Ceki Gulcu (was: Logback dev list)
AppenderBase and UnsynchronizedAppenderBsae do not allow exceptions to percolate to the application ---------------------------------------------------------------------------------------------------
Key: LBCORE-159 URL: http://jira.qos.ch/browse/LBCORE-159 Project: logback-core Issue Type: Improvement Components: Appender Affects Versions: 0.9.24 Environment: All Reporter: Ralph Goers Assignee: Ceki Gulcu Attachments: exceptionPatch.txt
When logging some events the application needs to be informed that the publishing of the event failed. Currently, AppenderBase and UnsynchronizedAppenderBase catch and handle all exceptions making it impossible to use any of the out-of-the box Logback appenders in these situations. This is particularly important when performing auditing and sending the events to a database, JMS queue, socket, etc. as the application would want to fail the current operation if it cannot be audited.
-- 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/LBCORE-159?page=com.atlassian.jira.plugin.system.i... ] Ceki Gulcu commented on LBCORE-159: ----------------------------------- Interesting approach to a non-trivial problem. The approach taken in logback-audit exposes the exceptions in the audit-logging API which is quite different than the logging API.I kind of like your way.
AppenderBase and UnsynchronizedAppenderBsae do not allow exceptions to percolate to the application ---------------------------------------------------------------------------------------------------
Key: LBCORE-159 URL: http://jira.qos.ch/browse/LBCORE-159 Project: logback-core Issue Type: Improvement Components: Appender Affects Versions: 0.9.24 Environment: All Reporter: Ralph Goers Assignee: Ceki Gulcu Attachments: exceptionPatch.txt
When logging some events the application needs to be informed that the publishing of the event failed. Currently, AppenderBase and UnsynchronizedAppenderBase catch and handle all exceptions making it impossible to use any of the out-of-the box Logback appenders in these situations. This is particularly important when performing auditing and sending the events to a database, JMS queue, socket, etc. as the application would want to fail the current operation if it cannot be audited.
-- 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/LBCORE-159?page=com.atlassian.jira.plugin.system.i... ] Ralph Goers commented on LBCORE-159: ------------------------------------ Obviously, so do I. I've commented before that I prefer just having Logback classic with sufficient capabilities to work for "nomal" logging as well as audit logging. That saves on having to reimplement Appenders and such with very minor differences. I'd appreciate it if you could apply this as I need to make changes to the JMS appenders to support layouts (similar to what I have in in my branch in git) and I'd prefer not to have to reimplement all the base classes.
AppenderBase and UnsynchronizedAppenderBsae do not allow exceptions to percolate to the application ---------------------------------------------------------------------------------------------------
Key: LBCORE-159 URL: http://jira.qos.ch/browse/LBCORE-159 Project: logback-core Issue Type: Improvement Components: Appender Affects Versions: 0.9.24 Environment: All Reporter: Ralph Goers Assignee: Ceki Gulcu Attachments: exceptionPatch.txt
When logging some events the application needs to be informed that the publishing of the event failed. Currently, AppenderBase and UnsynchronizedAppenderBase catch and handle all exceptions making it impossible to use any of the out-of-the box Logback appenders in these situations. This is particularly important when performing auditing and sending the events to a database, JMS queue, socket, etc. as the application would want to fail the current operation if it cannot be audited.
-- 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/LBCORE-159?page=com.atlassian.jira.plugin.system.i... ] Ralph Goers commented on LBCORE-159: ------------------------------------ Just wondering if you plan on applying the patch.
AppenderBase and UnsynchronizedAppenderBsae do not allow exceptions to percolate to the application ---------------------------------------------------------------------------------------------------
Key: LBCORE-159 URL: http://jira.qos.ch/browse/LBCORE-159 Project: logback-core Issue Type: Improvement Components: Appender Affects Versions: 0.9.24 Environment: All Reporter: Ralph Goers Assignee: Ceki Gulcu Attachments: exceptionPatch.txt
When logging some events the application needs to be informed that the publishing of the event failed. Currently, AppenderBase and UnsynchronizedAppenderBase catch and handle all exceptions making it impossible to use any of the out-of-the box Logback appenders in these situations. This is particularly important when performing auditing and sending the events to a database, JMS queue, socket, etc. as the application would want to fail the current operation if it cannot be audited.
-- 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/LBCORE-159?page=com.atlassian.jira.plugin.system.i... ] Ralph Goers commented on LBCORE-159: ------------------------------------ I would really like this patch applied asap.
AppenderBase and UnsynchronizedAppenderBsae do not allow exceptions to percolate to the application ---------------------------------------------------------------------------------------------------
Key: LBCORE-159 URL: http://jira.qos.ch/browse/LBCORE-159 Project: logback-core Issue Type: Improvement Components: Appender Affects Versions: 0.9.24 Environment: All Reporter: Ralph Goers Assignee: Ceki Gulcu Attachments: exceptionPatch.txt
When logging some events the application needs to be informed that the publishing of the event failed. Currently, AppenderBase and UnsynchronizedAppenderBase catch and handle all exceptions making it impossible to use any of the out-of-the box Logback appenders in these situations. This is particularly important when performing auditing and sending the events to a database, JMS queue, socket, etc. as the application would want to fail the current operation if it cannot be audited.
-- 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/LBCORE-159?page=com.atlassian.jira.plugin.system.i... ] Ceki Gulcu commented on LBCORE-159: ----------------------------------- Let us keep in mind that the appendLoopOnAppenders in Logger assumes that appenders do *not* throw exceptions. Consider a set up where a logger, say L, has appenders A and B attached to it. If the present patch is applied, how would we deal with the situation where appender A throws an exception? Should we still try to invoke the doAppend method on B? If we decide to invoke B and it also throws an exception, should we percolate the exception generated by A or that generated by B? I would like to see an attempt to answer these questions before the patch is applied.
AppenderBase and UnsynchronizedAppenderBsae do not allow exceptions to percolate to the application ---------------------------------------------------------------------------------------------------
Key: LBCORE-159 URL: http://jira.qos.ch/browse/LBCORE-159 Project: logback-core Issue Type: Improvement Components: Appender Affects Versions: 0.9.24 Environment: All Reporter: Ralph Goers Assignee: Ceki Gulcu Attachments: exceptionPatch.txt
When logging some events the application needs to be informed that the publishing of the event failed. Currently, AppenderBase and UnsynchronizedAppenderBase catch and handle all exceptions making it impossible to use any of the out-of-the box Logback appenders in these situations. This is particularly important when performing auditing and sending the events to a database, JMS queue, socket, etc. as the application would want to fail the current operation if it cannot be audited.
-- 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/LBCORE-159?page=com.atlassian.jira.plugin.system.i... ] Ralph Goers commented on LBCORE-159: ------------------------------------ You've raised some very valid questions. First, to cause the exception to be thrown the Appender must be configured to do so, so the user must be explicitly aware of the behavior they are causing. The implication in doing this is that the Appender is critical and must succeed. From that standpoint, without making changes to Logger the user has some options. Assume A is configured to percolate exceptions and B is not. If B is placed before A then it will process the event before B has a chance to throw the exception. If B is placed after then it will only be invoked if A succeeds. For my purposes these two options are enough. However, if I wanted the behavior you describe I wouldn't do it by modifying Logger. I would create an Aggregate Appender that could take extra configuration to identify whether an Appender should always be called even if a predecessor fails, and provide support for "fallback" appenders that can be invoked if a primary appender throws an exception, etc.
AppenderBase and UnsynchronizedAppenderBsae do not allow exceptions to percolate to the application ---------------------------------------------------------------------------------------------------
Key: LBCORE-159 URL: http://jira.qos.ch/browse/LBCORE-159 Project: logback-core Issue Type: Improvement Components: Appender Affects Versions: 0.9.24 Environment: All Reporter: Ralph Goers Assignee: Ceki Gulcu Attachments: exceptionPatch.txt
When logging some events the application needs to be informed that the publishing of the event failed. Currently, AppenderBase and UnsynchronizedAppenderBase catch and handle all exceptions making it impossible to use any of the out-of-the box Logback appenders in these situations. This is particularly important when performing auditing and sending the events to a database, JMS queue, socket, etc. as the application would want to fail the current operation if it cannot be audited.
-- 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/LBCORE-159?page=com.atlassian.jira.plugin.system.i... ] Ralph Goers edited comment on LBCORE-159 at 10/13/10 4:09 PM: -------------------------------------------------------------- You've raised some very valid questions. First, to cause the exception to be thrown the Appender must be configured to do so, so the user must be explicitly aware of the behavior they are causing. The implication in doing this is that the Appender is critical and must succeed. From that standpoint, without making changes to Logger the user has some options. Assume A is configured to percolate exceptions and B is not. If B is placed before A then it will process the event before A has a chance to throw the exception. If B is placed after then it will only be invoked if A succeeds. For my purposes these two options are enough. However, if I wanted the behavior you describe I wouldn't do it by modifying Logger. I would create an Aggregate Appender that could take extra configuration to identify whether an Appender should always be called even if a predecessor fails, and provide support for "fallback" appenders that can be invoked if a primary appender throws an exception, etc. was (Author: rgoers@apache.org): You've raised some very valid questions. First, to cause the exception to be thrown the Appender must be configured to do so, so the user must be explicitly aware of the behavior they are causing. The implication in doing this is that the Appender is critical and must succeed. From that standpoint, without making changes to Logger the user has some options. Assume A is configured to percolate exceptions and B is not. If B is placed before A then it will process the event before B has a chance to throw the exception. If B is placed after then it will only be invoked if A succeeds. For my purposes these two options are enough. However, if I wanted the behavior you describe I wouldn't do it by modifying Logger. I would create an Aggregate Appender that could take extra configuration to identify whether an Appender should always be called even if a predecessor fails, and provide support for "fallback" appenders that can be invoked if a primary appender throws an exception, etc.
AppenderBase and UnsynchronizedAppenderBsae do not allow exceptions to percolate to the application ---------------------------------------------------------------------------------------------------
Key: LBCORE-159 URL: http://jira.qos.ch/browse/LBCORE-159 Project: logback-core Issue Type: Improvement Components: Appender Affects Versions: 0.9.24 Environment: All Reporter: Ralph Goers Assignee: Ceki Gulcu Attachments: exceptionPatch.txt
When logging some events the application needs to be informed that the publishing of the event failed. Currently, AppenderBase and UnsynchronizedAppenderBase catch and handle all exceptions making it impossible to use any of the out-of-the box Logback appenders in these situations. This is particularly important when performing auditing and sending the events to a database, JMS queue, socket, etc. as the application would want to fail the current operation if it cannot be audited.
-- 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/LBCORE-159?page=com.atlassian.jira.plugin.system.i... ] Ralph Goers edited comment on LBCORE-159 at 10/13/10 4:10 PM: -------------------------------------------------------------- You've raised some very valid questions. First, to cause the exception to be thrown the Appender must be configured to do so, so the user must be explicitly aware of the behavior they are causing. The implication in doing this is that the Appender is critical and must succeed. From that standpoint, without making changes to Logger the user has some options. Assume A is configured to percolate exceptions and B is not. If B is placed before A then it will process the event before A has a chance to throw the exception. If B is placed after then it will only be invoked if A succeeds. For my purposes these two options are enough. However, if I wanted the behavior you describe I wouldn't do it by modifying Logger. I would create an Aggregate Appender that could take extra configuration to identify whether an Appender should always be called even if a predecessor fails, and provide support for "fallback" appenders that can be invoked if a primary appender throws an exception, etc. I don't think adding any more logic to Logger is a very good idea. was (Author: rgoers@apache.org): You've raised some very valid questions. First, to cause the exception to be thrown the Appender must be configured to do so, so the user must be explicitly aware of the behavior they are causing. The implication in doing this is that the Appender is critical and must succeed. From that standpoint, without making changes to Logger the user has some options. Assume A is configured to percolate exceptions and B is not. If B is placed before A then it will process the event before A has a chance to throw the exception. If B is placed after then it will only be invoked if A succeeds. For my purposes these two options are enough. However, if I wanted the behavior you describe I wouldn't do it by modifying Logger. I would create an Aggregate Appender that could take extra configuration to identify whether an Appender should always be called even if a predecessor fails, and provide support for "fallback" appenders that can be invoked if a primary appender throws an exception, etc.
AppenderBase and UnsynchronizedAppenderBsae do not allow exceptions to percolate to the application ---------------------------------------------------------------------------------------------------
Key: LBCORE-159 URL: http://jira.qos.ch/browse/LBCORE-159 Project: logback-core Issue Type: Improvement Components: Appender Affects Versions: 0.9.24 Environment: All Reporter: Ralph Goers Assignee: Ceki Gulcu Attachments: exceptionPatch.txt
When logging some events the application needs to be informed that the publishing of the event failed. Currently, AppenderBase and UnsynchronizedAppenderBase catch and handle all exceptions making it impossible to use any of the out-of-the box Logback appenders in these situations. This is particularly important when performing auditing and sending the events to a database, JMS queue, socket, etc. as the application would want to fail the current operation if it cannot be audited.
-- 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) -
Ralph Goers (JIRA)