On 2013-08-12, Dominik Psenner wrote:
> The log filename should be determined dynamically to allow users including
> information like %date, %time in the filename. It has often been requested
> and up to now it is supported only marginally.
+1
> Another issue that I just remembered now is that currently there's no
> way to roll empty files on date/time boundaries. Rolling only happens
> when a log event is generated. If there's no log event, files won't be
> rolled. Thus we should investigate if we should implement the appender
> as a buffering async appender that does the rolling in his async work
> cycles and whose work cycles do not depend on the availability of log
> events.
I already said I'm not sure mixing this into async is the way to go. It
may be easier to just start timers if the rolling condition is a time
based one. No strong opinion here, though, as I haven't thought through
either approach.
> Futher, the rolling file appender should probably receive a persistent
> storage where he can keep a set of rolled files he has rolled in the
> past.
You've looked into this far more than I have but do your really feel the
persistent storage is needed? To me scenarios like "I have manually
deleted some log files" or "I have reconfigured the rolling conditions"
don't really have to be supported by our rolling logic. If people
interfere with rolling they better clean up themselves IMHO.
> That means that a rolling strategy could be an interface like:
> public interface RollingStrategy {
> public void DoRolling(RollingContext context);
and DoRolling would do what? Perform the actual rolling our just tell
us whether log files should be rolled? In the first case all those
strategies would implement the same copy file X.i to file X.i+1 logic
somewhere. Feels wrong.
> The next topic is the rolling condition. The rolling condition decides if
> rolling should be done right now.
OK, this answers part of my question above. So what does
RollingStrategy do?
> Making the rolling condition pluggable would greatly benefit others to
> invent their own rolling conditions.
Absolutely.
> And now we come to the disposal of old files.
I agree it should be separate from rolling and be as pluggable as the
rolling condition.
Stefan
