OK, did not know yet about this KeyFileAppender. it's implementation is showing the direction of my proposal, but...
1. my proposal is valid for all FileAppender's and its derivations (RollingFileAppender, DailyRollingFileAppender) and not only for a specialized subclass (hence design pattern 'strategy') 2. KeyFileAppender supports only one MDC value, and this is only appended to the configured filename. With my solution the app developper is free to build any filename (incl. different path) by using any arbitrary values taken from where he/she likes. 3. A mechanism for garbage collecting no more used files is a must. Some short hints to solve your problem of open files: 1. Each entry in your Writer Hashtable must have an additional field 'LastUse' of type Date which is updated to the actual system time on each use of the Writer. 2. a separate thread checks periodically all writers if the field LastUse is older than a certain timeout value (i.e. one hour). If so, it closes the writer. 3. Modifying access to this hashtable must be synchronized Heri > -----Original Message----- > From: news [mailto:[EMAIL PROTECTED] Behalf Of Leo Lima > Sent: Tuesday, October 03, 2006 4:16 PM > To: [email protected] > Subject: [SPAM (DNS Blacklist)] - Re: Enhanced FileAppender - Sending > mail server found on sbl-xbl.spamhaus.org > > > Hello Bender. > > > 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). > > > I used a KeyFileAppender I found for that porpouse. Take a look: > http://mail-archives.apache.org/mod_mbox/logging-log4j-user/20 > 0305.mbox/[EMAIL PROTECTED] > p.mpi.com%3E > I've been using it for months now. > > > > 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. > > > That's the problem I faced now that I handle over a thousand > file creations > a day... The filehandlers remain open forever. How do intend > to check for > open file handlers? A separated thread? Check on each login > event? I can't > find an easy way to do that without hindering the application > or the logging > events. > > Please, take a look at it and let's please find a solution. > I've even open a > thread at users list too, but I didn't post the problem properly... > > Regards, > Leo. > > > > > --------------------------------------------------------------------- > 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]
