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
|