logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bender Heri" <HBen...@Ergonomics.ch>
Subject RE: Enhanced FileAppender
Date Tue, 03 Oct 2006 16:00:59 GMT
hi Wyssli

1. Maybe I cited the wrong desing pattern. You probably right that the strategy pattern would
match cleaner (it's an academic question).

2. It's also a good idea to provide the method buildFileName with the LoggingEvent. But the
involved appender should also be known (in order to get the configured filename).

3. I don't understand your proposal "closeFileAfter()" depending on the event. Who should
call this? The appender? The log4j user? I think a configurable timeout would be the way.
See my response to Leo Lima some minutes ago.

Heri



> -----Original Message-----
> From: patrick [mailto:Patrick.Wyss@mobilesolutions.ch]
> Sent: Tuesday, October 03, 2006 11:09 AM
> To: log4j-dev@logging.apache.org
> Subject: Re: Enhanced FileAppender
> 
> 
> 
> hi heri,
> 
> i like the idea a lot.
> however (admittedly without thinking to much about it ;-} ) i'd use
> "Strategy pattern" 
> http://www.dofactory.com/Patterns/PatternStrategy.aspx
> 
> and something like:
> FileNameBuilder {
>  public String buildFilename( LoggingEvent event );
> }
> 
> maybe it would be an idea to add a method
>  public boolean closeFileAfter( LoggingEvent event );
> 
> to make it possible to close the files with a specific log event.
> 
> but that's just some quick toughts ;-}
> 
> best regards
> patrick
> 
> 
> 
> Bender Heri wrote:
> > 
> > Hello all
> > 
> > Since in user list nobody commented my suggestion for an 
> enhancement of
> > the FileAppender I will repeat it here.
> > 
> > Problem:
> > A often asked issue in user list is the problem to separate 
> log files
> > dependent on different criterias, like a client-ID in a server
> > environment, a mandant- or task-ID in scheduler applications, etc.
> > Although it is possible to achieve this with the existing 
> log4j framework
> > all possible solutions are quite complex  or have other 
> drawbacks (own
> > repository selector, working with different classloaders, subclass
> > concrete descendents of FileAppender).
> > 
> > Solution:
> > The FileAppender is supplied with a property of type FileNameBuilder
> > (Design pattern: visitor). The user-supplied implementation of this
> > Interface can build a filename based on whatever criterias 
> (i.e. MDC,
> > global Environment, etc.). The visitor is called each time 
> a Fileappender
> > wants to append a log message. The FileAppender holds a 
> collection of file
> > writers for each separate file name delivered by FileNameBuilder.
> > To avoid the excess of open file handles the FileAppender 
> could watch the
> > logging activity to one particular file. If the file was 
> not accessed
> > after let's say one hour it could be closed (this timeout 
> could also be
> > configurable). Special care must be done if the property 
> "append" of the
> > FileAppender is false. If the file was closed because the 
> above timeout
> > had elapsed and then reopened later again, the file shouldn't be
> > overridden.
> > If the config file does not specify a FileNameBuilder a default
> > implementation would be used which returns always the 
> configured filename.
> > This wouldn't break existing code. The existing property 
> fileName would
> > remain and hold always the configured filename.
> > 
> > The interface of the FileNameBuilder would be like this:
> > 
> > public String buildFilename( FileAppender aFileAppender );
> > 
> > 
> > Any comments on this?
> > 
> > 
> > Heri
> > 
> 

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


Mime
View raw message