logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Grabowski <rongrabow...@yahoo.com>
Subject Re: Enhanced FileAppender
Date Thu, 05 Oct 2006 23:47:27 GMT
NLog's (a well written logging library inspired by log4net) FileTarget (read: FileAppender)
supports the features you're describing:


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 <HBender@Ergonomics.ch>
To: log4j-dev@logging.apache.org
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.

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).

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?


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

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

View raw message