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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
