Re: AW: [SPAM (Bayesain Analysis)] - Repository selectors, useful? - Bayesian Filter detected spam

2008-11-27 Thread Ceki Gulcu

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]



AW: [SPAM (Bayesain Analysis)] - Repository selectors, useful? - Bayesian Filter detected spam

2008-11-26 Thread Bender Heri
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



-Ursprüngliche Nachricht-
Von: Ceki Gulcu [mailto:[EMAIL PROTECTED] 
Gesendet: Freitag, 26. Dezember 2008 14:06
An: Log4J Users List
Betreff: [SPAM (Bayesain Analysis)] - Repository selectors, useful? - Bayesian 
Filter detected spam


Hello,

I am in the process of fixing bugs related to context selectors in logback.
Context selectors are the equivalent of repository selectors in log4j. However, 
while few years back I thought that context selectors, aka repository 
selectors, were the wave of the future, I am increasingly skeptical about their 
usefulness.

If you are using context/repository selectors, could you please explain why?

--
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]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]