NLog's (a well written logging library inspired by log4net) FileTarget (read: FileAppender) supports the features you're describing:
http://svn.nlog-project.org/repos/nlog/trunk/NLog/src/NLog/Targets/File.cs I haven't used it personally but from glancing at the source (specifically the Initialize method) it appears that they are able to manage several open appenders to support requirements like one log file per user. NLog has a bunch of other neat features that future versions of log4j or log4net might find useful. ----- Original Message ---- From: Bender Heri <[EMAIL PROTECTED]> To: [email protected] Sent: Monday, October 2, 2006 2:12:26 PM Subject: Enhanced FileAppender 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
