Thank for the response Curt. On Wednesday 27 April 2005 10:30 am, Curt Arnold wrote: > I wasn't aware of an ExternallyRolledFileAppender and didn't see it in > the obvious places in the CVS attic.
http://cvs.apache.org/viewcvs.cgi/logging-log4j/src/java/org/apache/log4j/varia/ExternallyRolledFileAppender.java?hideattic=0&rev=1.15&view=markup > log4j 1.3 adds a new architecture for rolling file appenders with > pluggable triggering and naming policies. In addition to the time and > size based triggers to support log4j 1.2 rolling behaviors, > o.a.l.rolling.FilterBasedTrigger (in CVS but not in any release yet) > can be used to force rolling based on the content of a message and if > that is not adequate you could develop your own trigger. If either > case, you will need to dispatch a message to force evaluation of the > trigger. This sounds like a much cleaner model, but I won't be able to use it in my applications until 1.3 is at least a RC. > To see an example of message triggered rolling see > tests/input/rolling/filter1.xml and > tests/src/java/org/apache/log4j/rolling/FilterBasedRollingTest.java. > > I would appreciate any feedback, positive or otherwise. > > p.s. The signature for o.a.l.Rolling.TriggeringPolicy.isTriggeringEvent > is likely to change. The File parameter is used in the size based > trigger, but the size returned from File.length() is unreliable during > logging on Windows. My current thinking is to keep a running size of > the log within the appender and pass that to the trigger which might > result in a signature like: > > boolean isTriggeringEvent(final Appender appender, final long length, > final LoggingEvent event); Why not continue to pass in the file, it could be used for other triggers besides length. --Jason --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
