[
https://issues.apache.org/jira/browse/LOGCXX-523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17324555#comment-17324555
]
Robert Middleton commented on LOGCXX-523:
-----------------------------------------
Using the following configuration does let the fallback work:
{code:xml}
<?xml version="1.0" encoding="UTF-8" ?>
<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/";>
<appender name="Rolling" class="log4cxx.RollingFileAppender">
<param name="File" value="test.log" />
<errorHandler class="org.apache.log4j.varia.FallbackErrorHandler">
<root-ref/>
<appender-ref ref="FallbackRolling" />
</errorHandler>
<rollingPolicy class="org.apache.log4j.rolling.FixedWindowRollingPolicy">
<param name="fileNamePattern" value="test-%i.log.gz"/>
</rollingPolicy>
<triggeringPolicy class="log4cxx.rolling.SizeBasedTriggeringPolicy">
<param name="maxFileSize" value="500"/>
</triggeringPolicy>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%d{ISO8601} %-5X{LWPID} %-7p
%-20.20c | %m%n"/>
</layout>
</appender>
<appender name="FallbackRolling" class="log4cxx.RollingFileAppender">
<param name="File" value="test.log" />
<rollingPolicy class="org.apache.log4j.rolling.FixedWindowRollingPolicy">
<param name="fileNamePattern" value="test-%i.log"/>
</rollingPolicy>
<triggeringPolicy class="log4cxx.rolling.SizeBasedTriggeringPolicy">
<param name="maxFileSize" value="500"/>
</triggeringPolicy>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%d{ISO8601} %-5X{LWPID} %-7p
%-20.20c | %m%n"/>
</layout>
</appender>
<root>
<priority value ="debug" />
<appender-ref ref="Rolling" />
</root>
<logger name="unused">
<appender-ref ref="FallbackRolling"/>
</logger>
</log4j:configuration>
{code}
Caveats:
* You need to add the fallback appender to some logger, even if that logger
isn't used. This is because if the are no references to it, the appender will
be destroyed because of the smart pointers. We may need to think about keeping
a list of all appenders, even if they are unused.
* The rollover may be weird with the given configuration,as the two appenders
want to write to the same file. This doesn't appear to cause any issues as far
as I can tell at the moment.
* The error handler mechanism needs to be more robust and have better cleanup
on errors. When this fails, it will leave a 0-byte gz file in the log output
directory, as it wasn't able to execute gzip properly.
> Add in error handling for rollover errors
> -----------------------------------------
>
> Key: LOGCXX-523
> URL: https://issues.apache.org/jira/browse/LOGCXX-523
> Project: Log4cxx
> Issue Type: Improvement
> Reporter: Robert Middleton
> Assignee: Robert Middleton
> Priority: Major
> Fix For: 0.12.0
>
>
> As reported in a PR, if the rollover fails(because you have run out of memory
> for example), then logging will stop. The only error that the user sees is
> that an exception occurred during the rollover. This is very unhelpful.
> In order to fix this, update the RollingFileAppender classes to call the
> error handler if an error happens during rollover. The error handler should
> already be defined as part of the parent Appender class.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
