Ralph Goers - 23/Jul/10 07:51 PM The attached patch allows an Appender to be configured to percolate exceptions to the application.

Ceki Gulcu - 24/Jul/10 12:17 AM 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.

Ralph Goers - 24/Jul/10 06:40 AM 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.

Ralph Goers - 13/Aug/10 01:18 AM Just wondering if you plan on applying the patch.

Ralph Goers - 13/Oct/10 08:34 AM I would really like this patch applied asap.

Ceki Gulcu - 13/Oct/10 11:18 AM 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.

Ralph Goers - 13/Oct/10 04:08 PM - edited 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.