logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject RE: RFE - Fixed Memory Logging
Date Tue, 04 May 2004 13:53:54 GMT


I suggest you have a look at the code under the package 
org.apache.log4j.rolling in CVS head which follows a pattern similar to 
what you describe. There is no real point in discussing the design of 
existing code as if one was starting from scratch. You can just copy 
o.a.l.rolling into log4j 1.2.x and use it.

I hope this helps,

At 01:22 AM 5/4/2004, Alan Brown wrote:
>Forgive me if this simple design doesn't fit into the design decisions
>and needs of version 1.3.  It's based on the current production code,
>which I've got some familiarity with.  Forgive me also if my logic is
>deeply flawed or my design style repugnant.
>With that said...
>My design really only applies to FileAppenders, either Rolling,
>DailyRolling or, in the future, with a user defined renaming structure
>and user defined rolling rules.
>There appears to be 2 hooks needed in the code to do this job, one to
>enable defining of when files should rollover, and another to specify
>how it should be done.
>An interface, (RolloverStrategy?) would have 2 methods
>shouldRollover(String s)
>shouldRollover() would be called at the beginning of the subAppend()
>method in the FileAppender hierarchy and would be passed the string that
>would be about to be written to the logFile.  If shouldRollover()
>returned true then rollover() would then be called.
>This method might allow for a simplification of the RollingFileAppender
>class, with some of it's current functionality put in a
>BasicRolloverStrategy(?) class and an equivalent class made for the
>DailyRollingFileAppender class.
>I could then design a fixed storage strategy as follows:
>Each RollingFileAppender would have it's own instance of my rollover
>strategy class.  This would be so each rolloverStrategy class would be
>rolling over to their own destinations.  However, all of these instances
>would possess the same instance of a LogFileManager class, that would
>hear about the length of every append in every appender (via the fact
>that the shouldRollover() method will receive the length of the string
>to be written and will pass it along to my global manager).  The
>LogFileManager would then delete the oldest logfile in it's catalog when
>the limit was reached and would keep deleting the oldest file until it
>reached a second, acceptable storage usage.
>When an individual strategy instance had its rollover method called, it
>would pass the new file names and other pertinent info (file length, and
>last modified values) to the LogFileManager class so it would always be
>aware of all the files in its domain.  Finally, the LogFileManager must
>be passed the log directories during instantiation so it knows the file
>information for all the legacy log files.
>Again, I may very well have made some egregious error in my design as it
>has come from a very specific vantage point, ie, what would be the
>simplest class structure would enable me to implement the functionality
>for a fixedStorageFileAppender.
>Comments/flames welcomed...

Ceki Gülcü

      For log4j documentation consider "The complete log4j manual"
      ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp  

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message