On Apr 27, 2005, at 5:33 PM, Jason Calabrese wrote:
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
Thanks. I'm not really familiar with the varia tree.
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.
Other log4j 1.2 rolling file appenders (org.apache.log4j.RollingFileAppender and DailyRollingFileAppender) had been removed from the CVS. To allow applications that had been using them to migrate to log4j 1.3, I created emulations based on the new framework that should be functionally equivalent. Likely the ExternallyRollingFileAppender was removed at the same time. I'll have need to investigate the history and see if a similar emulation is warranted. If so, then your app could continue to use ExternalRollingFileAppender in both log4j 1.2 and 1.3 until ready to commit to 1.3.
Are there any other RollingAppenders that have disappeared?
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.
I included the appender parameter to attempt to provide for "unexpected" triggers and to preserve the ability to obtain the File by interrogating the appender. However, very little in the File object would be current while it is open for appending so I saw very little utility to have it directly available. There is no code backing this up at the moment and it would be no big deal to add it if there is some justification.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
