What about making the file creation and disposal pluggable in a sense that
one must implement an interface with a GetNewLogFileName() method and
another interface responsible for disposing the files created by the first
interface.
If the user wished he can use the implementation that persists the data and
on the first call to the disposing method the cache will be read and the
files will be deleted and if he doesn't want to use the persistence storage
he can use the implementation that rolls files by name like the old RFA.
On Mon, Aug 26, 2013 at 10:14 AM, Dominik Psenner <dpsen...@gmail.com>wrote:
> 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</disposedLogfileFormat>
> ****
>
> </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 Rol
> lingFileAppender****
>
> ** **
>
> 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>
> 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? J****
>
> ****
>
> 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>
> wrote:****
>
> On 2013-08-14, Dominik Psenner wrote:
>
> > 2013/8/14 Stefan Bodewig <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****
>
> ****
>
> ** **
>
