Good Morning,

 

I understand your point. That would be exactly how the current RFA behaves.
However, people are lazy and when something doesn't work they are first
frustrated and then they may throw the framework over board or ask silly
questions. The latter happens about once every month. It is not nice to have
the answer ready "this is not supported and it won't ever be" because then
discussions start about the why-not and may-not-be or could-we-not.

 

As I see it, the time has come that we should provide a solution that works.
There are times when documentation does solve an issue but this time it is
not. Of course this is not an easy task, but easy tasks are annoying anyway.
Hard tasks make the life tasty, don't they? :)

 

Cheers

 

Von: d_k [mailto:mail...@gmail.com] 
Gesendet: Dienstag, 20. August 2013 21:16
An: Log4NET Dev
Betreff: Re: Ideas for a new RollingFileAppender

 

Will it be reasonable to say that as long as the target folder path is
static log4net will clean up old files and if the target folder path is
dynamic it will clean them as long as the process is up?

 

On Thu, Aug 15, 2013 at 4:44 PM, Stefan Bodewig <bode...@apache.org
<mailto:bode...@apache.org> > wrote:

On 2013-08-14, Dominik Psenner wrote:

> 2013/8/14 Stefan Bodewig <bode...@apache.org <mailto:bode...@apache.org> >

>>> The application runs for 3 days and thus log4net rolls the logfile 3
>>> times.

>> Well, I live in a world where all log files of an application are kept
>> inside the same folder :-)

> For me too, but I've seen enough to know better.

Might be a matter of educating the culprits.

Yes, I know things like this happen.


>> More seriously, to me it sounds like a bit of feature creep.  I wouldn't
>> consider my logging framework to be the one who's responsible for
>> mailing non empty files on rolling.  That's the job of
>> logrotate/logwatch or similar specialiced tools IMHO.  One could even
>> argue disposal of logfiles should be out of scope.  Maybe that's just
>> me.

> Yes and no. The framework should at least be able to prevent filesystem
> pollution by itself when told to clean up after itself.

I'm not sure I agree with that.  But arguing against that is almost
arguing against having a RollingFileAppender in the first place.  So
I'll give in.

Stefan

 

Reply via email to