Hello,

I've had a read of that first document and got the idea of multiple repositories.

It seems to me that in this scenario it is essential to use instance variables for the 
Logger rather than the class level static variables I have been using thus far.

As I understand it, any class static Logger variables would just be initialized with 
the repository associated with whichever app. uses the class first.

This doesn't seem to be discussed anywhere although the issue is raised at the 
beginning of the document.

Is this correct?

Thanks,
D



> -----Original Message-----
> From: Ceki Gülcü [mailto:[EMAIL PROTECTED]
> Sent: 24 May 2004 18:17
> To: Log4J Users List
> Subject: Re: FW: Logging in Tomcat from classes in
> CATALINA_BASE/shared/lib
> 
> 
> 
> It looks like this problem is a variant of the "Logging 
> separation problem" 
> discussed at:
> 
>    https://www.qos.ch/logging/sc.html
> 
> You have several options
> 
> 1) use JNDIContextSelector which is natively supported in 
> log4j 1.3 (still 
> in development)
> 
> 2) write your own selector which fetches repositories from a 
> ThreadLocal. 
> This approach assumes that a
> <file://HttpSessionListener.html>HttpSessionListener or a 
> filter places the 
> correct repository before serving requests
> 
> I'd start with 1) and see if it solves the problem. 
> Interesting problem btw...
> 
> At 01:17 PM 5/24/2004, Alexander,D wrote:
> >Hi,
> >
> >Hope someone can advise.
> >
> >We have an unconventional deployment of our applications in 
> Tomcat (4.1.x) 
> >where, rather than deploying classes under each webapp, they 
> have been 
> >deployed together in a jar under CATALINA_BASE/shared/lib 
> alongside other 
> >library jars. We do this to ease deployment as we have a 
> large number of 
> >classes that are common across many applications.
> >
> >This may not be the 'correct' way to deploy them but that is 
> how it is, 
> >the applications work and it would be a large amount of work 
> to reorganise.
> >
> >We are considering using log4j to provide logging for these 
> apps. but it 
> >seems to me that our unconventional deployment makes this difficult.
> >
> >Please correct me if I am wrong, but in a normal deployment the 
> >application classes, log4j.jar and the log4j.configuration are all 
> >deployed under the webapp allowing control over the logging for that 
> >specific application.
> >
> >In our setup, we have lost the possiblity of control the 
> logging on a per 
> >application basis from the configuration file. The only 
> option we would 
> >have there is to set different logging levels and/or appenders to 
> >different points in the class/package hierarchy. However 
> this wouldn't 
> >provide much benefit to us as many classes are used by more than one 
> >application.
> >
> >As I see it, the only way around this is for us to use an 
> MDC in each of 
> >our Servlets to identify the application it belongs to, have 
> the Pattern 
> >print this value out and write a custom appender (or some 
> filtering later 
> >on) to separate the log entries for each application based 
> on this value.
> >
> >If anyone has any experience with logging classes from 
> >CATALINA_BASE/shared/lib I'd appreciate it. I wonder if I 
> have missed an 
> >easy trick and am making things too complicated.
> >
> >Also, as in this situation, I have log4j.jar also in 
> >CATALINA_BASE/shared/lib, where should I put the 
> log4j.configuration file 
> >for it to be picked up automatically?
> >
> >Thanks,
> >D.
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> 
> -- 
> Ceki Gülcü
> 
>       For log4j documentation consider "The complete log4j manual"
>       ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp  
> 
> 
> 
> ---------------------------------------------------------------------
> 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]

Reply via email to