Thanks for the replies. I've had a read through the docs on repositories and repository selectors. Will give that a go and report back.
Regards, D. > -----Original Message----- > From: Jacob Kjome [mailto:[EMAIL PROTECTED] > Sent: 24 May 2004 19:22 > To: Log4J Users List > Subject: Re: FW: Logging in Tomcat from classes in > CATALINA_BASE/shared/lib > > > Quoting "Alexander,D" <[EMAIL PROTECTED]>: > > > 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. > > > > So, you do, at least, have .war files, but the libraries they > depend on are in > shared/lib. Ok. > > > 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. > > > > Not overly. Just a bit more thought. > > > 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. > > > > That's one way which takes advantage of servlet spec > recommended classloading > behavior, although not all containers follow this, so it > isn't failsafe either. > However, since Tomcat follows this recommendation, it works > as advertised in > Tomcat. > > > 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. > > > > You just haven't been introduced the concept of logger > repositories and > repository selectors. This is what you need for your situation. > > > 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. > > > > See... > http://nagoya.apache.org/wiki/apachewiki.cgi?Log4JProjectPages /AppContainerLogging Check out logging-log4j-sandbox using the tag "LOG4J_SANDBOX_ALPHA3". This will include the ContextJNDISelector which was removed because it was moved to Log4j proper (but modified significantly making it incompatible with Log4j-1.2.x). > 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? > Well, first I'd put log4j.jar in common/lib, not shared/lib. Second, counting on automatic configuration means that you won't be using a custom repository selector and, hence, won't be using a separate logger repository per app leaving you with the same problem you're trying to solve (note that Log4j-1.3 makes things easier). Basically, read the javadoc for the InitContextListener and the ContextJNDISelector for information on configuring your applications to use separate logger repositories in a shared environment. Make sure to put log4j-sandbox.jar in shared/lib (or common/lib along with log4j, either is fine). Any more questions, let me know. Jake > Thanks, > D. > > > --------------------------------------------------------------------- > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
