[ 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