mdsadman-git commented on issue #3622: URL: https://github.com/apache/logging-log4j2/issues/3622#issuecomment-2830685361
@ppkarwasz, Thank you for your reply. Actually, While working on Log4j version update from v1 to v2, a Failover Appender was necessary for my requirement. While testing the Failover Appender, I tried with some approaches, like 1. Put wrong path in Primary Appender path variable 2. Throw an error at Primary Appender 3. Lock the log file [The appender I was using, was a RollingFile] so on... But I couldn't find a test case to call the secondary appenders. So I started checking the Log4j2 source and found the logic below.  I updated the logic like this, and it works without any issue. [*] Please let me know if this could cause any other issue.  Actually what I understand from the name 'Failover Appender' is that, - It is something that will invoke appenders as an optional element, starts with primary appender - No matter what happened to the Primary Appender and other Appenders try to run until the last one - If last one also fails then an exception might throw or some error log will show in the console -- -- > How to handle partial configuration startup failures is currently a grey area in Log4j Core. We [discussed this recently on dev@logging](https://lists.apache.org/thread/h2oydyk6xld47ljttqvflbt4530o73vw) and the consensus is that in cases like yours the whole Configuration object should be discarded and the old configuration should be used (or the default configuration if the first configuration fails). Would this be an acceptable solution? I understand the idea of default configuration but since there is Secondary Appenders already provided in the configuration, so those could be use as optional appenders. These optional appenders are actually default appender when fails. > The configuration problem you present in this issue is not a temporary problem accessing a resource, but a permanent one. IMHO it should either prevent the configuration from being used at all or propagate an exception to the caller (we can create a [configuration property](https://logging.apache.org/log4j/2.x/manual/systemproperties.html) for this). I think it is better to prevent the configuration from being used at all. Cause, propagating an exception might stop the application from running. - If there is a case like an application is relying on Failover Appender to just skip to next Appender scenario, Then that application might stop running for that exception. - But it is a good idea to add an optional parameter for throwing or logging the exception. Thank you. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
