See the inlines.. I've stripped whatever's no longer interesting.
>> 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.
Let's imagine a rolling condition that rolls every day. The dispose strategy
is to keep a maximum of 30 files and the rolled file format is:
C:/myfancypath/%date/logfile.log
The application runs for 3 days and thus log4net rolls the logfile 3 times.
At this point the application is restarted. How does the application detect
which files are part of the rolled over files? It would have to crawl the
entire hard drive for files that match the regex:
C:/myfancypatch/.*/logfile.log
Pretty stupid, isn't it?
On the other hand, if log4net had kept a logbook of its actions it could
simply look that one up and get the 3 rolled files in a jiffy. I've just
crossed my mind with another issue I haven't thought about. Namely, what
should happen with directories log4net created? Ideally log4net should
dispose not only every rolled file that matches the above regex, but also
the directories it created (if the directory is not empty etc.). Maybe the
new rolling file appender should even store a history of operations? Then a
dispose strategy could use that information to safely dispose of created
directories and files or do other fancy stuff.
>> 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.
Said like this it feels wrong, but imagine the following. Maybe someday
someone wants a rolling operation that mails a nonempty logfile every 24
hours to a specific address? IMHO, even if it's only one implementation that
log4net is going to support, it might be well worth to have it pluggable.
>> 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?
Do the actual rolling and inform the persistent history about what it did.
The dispose strategy can use the information in the persistent history to
roll back all those actions when the time has come.
Cheers
