[just changing the subject :-)]
On 2013-08-12, Dominik Psenner wrote:
> Yesterday it became quite late and I had not the mental force to write down
> my vision of the RFA reimplementation:
> 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.
> 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.
> 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.
> This way we eliminate the dark magic behind detecting rolled files. It
> allows the user also to modify or mix the rolling strategies and/or rolling
> filename configuration from one instance to the next. The persistence will
> have to include a set of filenames. It would probably be nice to allow
> people configuring a relative filepath that will be stripped from the
> filenames. Otherwise we would break the usecase where a user moves an
> application from, let's say, drive C: to drive D: along with all logfiles
> because the rolled filenames would no longer be found and some files would
> become zombies that pollute the drive. Thus a persistable rolling history
> class could look alike:
> Public class RollingHistory {
> Public List<string> Files { get; }
> To exchange information between the rolling strategies, rolling conditions
> and the rolling file appender itself we should probably use a data class.
> The name of it could be "RollingContext" and basically could be implemented
> like:
> public class RollingContext {
> public RollingHistory RollingHistory { get; }
> public string Logfile { get; }
> public long CurrentLogfileSize { get; }
> That means that a rolling strategy could be an interface like:
> public interface RollingStrategy {
> public void DoRolling(RollingContext context);
> which either throws exceptions on failure or returns true|false to notify
> the caller that something went wrong and log the errors into the log4net
> internal debug log.
> The next topic is the rolling condition. The rolling condition decides if
> rolling should be done right now. Thus its interface should be something
> like:
> public interface IRollingCondition {
> public bool IsRollingConditionMet(RollingContext context);
> Concrete rolling conditions could be:
> * Roll if filesize exceeds a specific limit
> * Roll if a specific date/time condition is met
> ==> this is already kind of supported with an implementation of a
> "cron"-like syntax
> Making the rolling condition pluggable would greatly benefit others to
> invent their own rolling conditions. For example an implementation of
> IRollingCondition like:
> public class ManualRollingCondition implements IRollingCondition {
> public static bool RollOnNextCycle = false;
> public bool IsRollingConditionMet(RollingContext context) {
> if(RollOnNextCycle) {
> // reset roll on next cycle
> RollOnNextCycle = false;
> return true;
> }
> return false;
> could let the application that uses log4net decide when a file should be
> rolled by a simple invoke to:
> ManualRollingCondition.RollOnNextCycle=true;
> And now we come to the disposal of old files. Since we have a persistent set
> of old files we should pass it into the disposing logic and the interface to
> it could look like:
> Public interface IDisposeStrategy {
> Public bool DoDisposal(RollingContext context);
> And a concrete implementation of it could be:
> Public class LimitNumberOfFilesDisposeStrategy implements IDisposeStrategy {
> Public int MaxNumberOfFiles { get; set; }
> Public bool DoDisposal(RollingContext context) {
> // delete all files in history
> While(MaxNumberOfFiles < Context.RollingHistory.Count) {
> If(Context.RollingHistory.Count == 0)
> Return true;
> // delete oldest file and persist the history
> // let it crash if someone has a logfile open and locked
> // and let the invoker decide if he wants to retry later
> Try {
> Delete(Context.RollingHistory.Oldest());
> Context.RollingHistory.Remove(Context.RollingHistory.Oldest());
> Context.RollingHistory.Persist();
> }
> Catch
> // internal logging
> Return false;
> }
> Return true;
> }
> Some of the ideas above are already implemented in the patch, but there are
> several things that are not yet finished.
> Von: Dominik Psenner [mailto:dpsen...@gmail.com]
> Gesendet: Sonntag, 11. August 2013 22:59
> An: Log4NET Dev
> Betreff: Re: Creating a development environment for resolving LOG4NET-367
> This is something that wouldn't work right now:
> <appender>
> <rollingfileappender>
> <filename>C:/fancydirectory/%processid/%username/%year/%month/mylogfile.log<
> /filename>
> <locking>inter-process</locking>
> <rollOn><date where="hour%3==0" /></rollOn>
> <rollTo>C:/fancydirectory/%processid/%username/%year/%month/%filenumber/mylo
> gfile.log</rollTo>
> <dispose><files where="filenumber > 50" /></dispose>
> </rollingfileappender>
> </appender>
> but we want it to work in the future. Of couse the syntax may be different,
> but it should be easy enough to write down how the RFA has to behave. Right
> now there are too many fancy flicks and switches that do things magically.
> Cheers
> 2013/8/11 Dominik Psenner <dpsen...@gmail.com <mailto:dpsen...@gmail.com> >
> See the inlines..
> 2013/8/10 d_k <mail...@gmail.com <mailto:mail...@gmail.com> >
> Paperizing ideas sounds good. How does the log4net project handle
> requirements? JIRA?
> Yes
> Are there any requirements other than the ones under the 'supercedes' list?
> Yes and no. It should be a rolling file appender that handles things smarter
> than the current one. If there are ideas they are welcome.
> It should roll files (obvious) on "rolling conditions" with a "rolling
> strategy" and dispose old files with a "dispose strategy".
> The rolling condition, rolling strategy and dispose strategy should be
> pluggable and configurable (i.e. they are interfaces that can be implemented
> in different ways).
> It should support dynamic filenames that may change over time
> It should support changes to the rolling strategy in respect of disposal of
> old files (i.e. between process instances).
> It should support all currently supported locking strategies.
> For now I can't think of more.
> I'm afraid I don't have a 'vision' for the RFA-NG but I think we can take
> the patch under log4net-patches, make sure to fix the 'supercedes' list and
> off we go.
> I wouldn't want to spend time on a grand design because we can't tell how
> long will it take, and I think it is better to ship a less than perfect
> RFA-NG and fix it later on when we'll know what we want than to postpone the
> next release indefinitely.
> We have a RFA that does not what we want. We don't need another one. If we
> reimplement it now and release it, we have another RFA with a public api we
> do not want to change - sounds familiar.
> BTW, no offense, but is there a chance it will be easier to fix the current
> RFA than to rewrite it?
> There are things that are unfixable with the current implementation without
> breaking the public API and that's something we dont want.
> Is there a way to measure a given implementation of any RFA to determine if
> its good enough?
> It's good enough when it boils eggs and toast my bread .. just joking. ;-)
> It's good enough when it does what we want from it.
> On Fri, Aug 9, 2013 at 8:00 PM, Dominik Psenner <dpsen...@gmail.com
> <mailto:dpsen...@gmail.com> > wrote:
> Howdie,
> the patch there is mainly a first implementation showing the road we would
> like to go. There are many things to be discussed and I would start with
> paperizing the ideas before starting the implementation. The
> reimplementation should solve all known current issues of the rolling file
> appender.
> The patches repository is nothing else than a repository that holds patches
> that can be applied to the log4net source, which is located at apache.org
> <http://apache.org> 's svn. It's there to materialize the ideas without
> requiring write permissions to the actual svn and can be used as a sandbox
> to play with ideas.
> I started off with an implementation as a patch and wanted to improve that
> patch until it is stable enough to join the log4net appenders in svn.
> Cheers
> 2013/8/9 d_k <mail...@gmail.com <mailto:mail...@gmail.com> >
> Hi,
> So I think I got a working development environment for log4net.
> I installed mercurial and forked the log4net-crew repository
> (https://bitbucket.org/NachbarsLumpi/log4net-crew) and the log4net-patches
> repository (https://bitbucket.org/NachbarsLumpi/log4net-patches) and applied
> the RFA-NG patch with 'hg import'.
> Should I prefer to use http://svn.apache.org/viewvc/logging/log4net/trunk
> over https://bitbucket.org/NachbarsLumpi/log4net-crew? Will svn and
> mercurial coexist peacefully?
> Do I need anything else to start developing?
> Should I create my own RFA-NG2 patch? Or perhaps RFA-NG-NNN for each bug in
> the supercedes list of LOG4NET-367
> (https://issues.apache.org/jira/browse/LOG4NET-367)?
> Are there any common pitfalls I should avoid?
