JocularJoe commented on LOG4NET-511:
Yes. I thought we'd keep the IFlushable interface, but implement it in
AppenderSkeleton as a virtual method that just returns true.
Appenders that derive from AppenderSkeleton would then not need to implement
IFlushable, instead would override AppenderSkeleton.Flush. Appenders that
implement IAppender but don't derive from AppenderSkeleton would decide whether
to opt in to IFlushable.
My thought was that this would help avoid appender developers (most of whom
will derive from AppenderSkeleton) implementing IFlushable with a non-virtual
method, and therefore making inheritance more difficult.
It's a minor point, but if it's going to be done, now's the time to do it.
> API to flush appenders
> Key: LOG4NET-511
> URL: https://issues.apache.org/jira/browse/LOG4NET-511
> Project: Log4net
> Issue Type: Wish
> Components: Appenders, Core
> Affects Versions: 1.2.15
> Environment: NA
> Reporter: Joe
> Priority: Minor
> Fix For: 2.0.6
> I would like to see an API that flushes any appenders that have buffered
> data. E.g. a method LogManager.Flush(). An application might call such a
> method at regular intervals, e.g. on a Timer.
> A naive implementation with the current log4net would iterate through
> appenders, looking for those that support flushing, and call the appender's
> flush method, e.g.:
> foreach (IAppender appender in
> BufferingAppenderSkeleton bas = appender
> as BufferingAppenderSkeleton;
> if (bas != null) bas.Flush();
> But (a) I'm not sure this is thread-safe and (b) there are potentially other
> appenders that may want to be able to flush data (e.g. a TextWriterAppender
> with ImmediateFlush = false).
> The request consists of:
> - Add an interface, IFlushableAppender or equivalent, with a single method
> - Implement this interface in all relevant appenders
> (BufferingAppenderSkeleton, TextWriterAppender, ...)
> - Add a thread-safe static Flush() method to LogManager.
This message was sent by Atlassian JIRA