logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gulcu <lis...@qos.ch>
Subject Re: AW: [SPAM (Bayesain Analysis)] - Repository selectors, useful? - Bayesian Filter detected spam
Date Thu, 27 Nov 2008 08:55:16 GMT
Hello Bender,

Thank you for your detailed response. I appreciate it.

I believe that the problem you describe, namely separation of logging
(per thread), can be accomplished by means other than repository
selectors.

Your requirements are duly noted. I intend to look into it and to offer a
more convenient solution in the coming days.

Cheers,

Bender Heri wrote:
 > Hallo Ceki
 >
 > I found log4j's RepositorySelector very useful, I think I would not
 > have been able to solved my problem without it.
 >
 > I use it in a System which is designed to maintain different
 > customers. A single customer should never see any data (or even know
 > about the existence) of other customers. So I needed to separate also
 > all logs. One core application is a scheduler app which maintains
 > different jobs which run at regular intervals (configured for each
 > customer and job kind). The jobs make heavy use of common libraries
 > (in fact most of the work is done within these libraries, which make a
 > lot of log outputs). This log outputs should never mix between
 > customers and jobs.
 >
 > Such a job is running in its own thread. Therefore I can use the MDC
 > which is feeded at every thread start with infos about the current job
 > and the current customer. This info is then used by the repository
 > selector for choosing the correct repository (where file appenders are
 > defined with filenames and storage locations mirroring these MDC
 > infos).
 >
 > Maybe your new logback has other useful constructs to solve such a
 > problem. Using Log4j's RepositorySelector was a bit hard to understand
 > at the beginning, specially the need for having special logging code
 > (MDC, configuring the file appenders) at every thread start (was a bit
 > complex in combination with a thread pooling). I wished that such
 > things could be done only by configuration. More problems: Logger
 > instances in library classes cannot be instantiated statically, and
 > utility classes with static methods and other singletons must fetch
 > the logger on each method entry (I had to disable log outputs from
 > third party libraries which do not obey such circumstances).
 >
 > Greetings
 > Heri Bender
 >
-- 
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch

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


Mime
View raw message