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:[EMAIL PROTECTED] > Sent: Tuesday, October 03, 2006 11:09 AM > To: [email protected] > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
