I agree. The user has to be aware of that special file but I wouldn't make
it "switchable" because it implicitly limits the available configurations in
other places and the user probably does not know. We have a similar magic
toggle in the current RFA which is named "staticLogFileName". That toggle
disables rolling over date when set.
Still, optional configuration values are a matter of agreement and we can
find sensible ones by asking the user list with a poll. I've lately spent
some time thinking about how a configuration of the new RFA could look like
(in XML) and this is what my brain came up with:
<appender type="RFA2" name="RFA2.mine">
<logfileFormat>logs/mylogfile.log</logfileFormat>
<rollingConfiguration>
<fileCacheFile>${appender.name}.cache</fileCacheFile>
<lockingModel type="minimal" />
<rollingConditions>
<rollingCondition
type="startup" /> <!- rolls files on startup; this is equivalent to the
behaviour when one configures appendToFile=false in the current RFA --!>
<rollingCondition
type="cron">
<pattern>*/5
* * *</pattern> <!-roll every 5 minutes --!>
</rollingCondition>
<rollingCondition
type="cron">
<pattern>0,5,10,15,20,25,30,35,40,45,50,55 * * *</pattern> <!-alternative
but semantically equivalent pattern --!>
</rollingCondition>
<rollingCondition
type="cron">
<!-yet
another alternative but semantically equivalent pattern --!>
<pattern
minute="*/5" hour="*" day="*" dow="*" month="*" />
</rollingCondition>
<rollingCondition
type="filesize">
<maxFileSize
unit="mb">5</maxFileSize> <!-roll if filesize exceeds 5mb --!>
</rollingCondition>
</rollingConditions>
<rollingStrategy
type="defaultRollingStrategy">
<!-rolls a rolled file to the
specified file name format; ${datetime.original} would be the date/time when
the original logfile was first rolled --!>
<rolledLogfileFormat>logs/mylogfile-${datetime.original}-{$file.index}.log</
rolledLogfileFormat>
</rollingStrategy>
<disposeConditions>
<disposeCondition
type="filecount">
<maxFileCount>10</maxfileCount> <!-dispose rolled files if there are 10
newer files --!>
</disposeCondition>
<disposeCondition
type="fileage">
<maxFileAge
unit="days">30</maxFileAge>
</disposeCondition>
</disposeConditions>
<disposeStrategy type="moveFile">
<disposedLogfileFormat>logs/old/mylogfile-${datetime}-${file.index}.log</dis
posedLogfileFormat>
</disposeStrategy>
</rollingConfiguration>
</appender>
I would for instance default these properties like this:
fileCachefile: may always default to "${appender.name}.cache"
lockingModel: may default to "minimal"
rollingConditions: may default to "file size exceeds 1mb"
disposeStrategy: may default to "delete file"
Cheers
Von: d_k [mailto:mail...@gmail.com]
Gesendet: Sonntag, 25. August 2013 18:41
An: Log4NET Dev
Betreff: Re: Ideas for a new RollingFileAppender
Hard tasks are fun, but I wouldn't want the next version to be stuck forever
because of it.
What if we make it optional?
If the user wishes to roll dynamic paths he should flip a switch and specify
a target path that should be writable.
I don't think you can make it totally headless because the user still needs
to be aware a file is written and he needs write permissions to it, so we
might as well make the default implementation work without creating files
and provide an implementation that persists the data locally.
So applications that upgrade to the new version behave the same.
On Fri, Aug 23, 2013 at 10:54 AM, Dominik Psenner <dpsen...@gmail.com
<mailto:dpsen...@gmail.com> > wrote:
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 <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
