Jake,
Very good question. Log4j 1.2 introduced the concept of RepositorySelectors specifically to deal with this problem. Unless the container does for you (which Tomcat does not) you'd have to write your own RepositorySelector. Writing a selector is trivial if you control the application context... which you don't. I am including a chapter on this subject in my log4j book. Remind me to send you a free copy when it comes out. At 07:51 30.05.2002 -0500, Jacob Kjome wrote: >I was reading the Log4j manual and it suggests that for each webapp, you >should use a separate log4j jar file in each WEB-INF/lib to make sure that >each log4j is in its own "log4j Universe". However, this puts constraints >on where I put my libraries that use log4j. For instance, if I have log4j >in WEB-INF/lib, I can't have libraries that use log4j in TOMCAT_HOME/lib >because the libraries in the parent classloader won't find the Log4j >libraries in the child classloader. However, that is where I'd like to >put some of my libraries since they are common to all my webapps. In >fact, Log4j is common to all my webapps so I'd like to put it in >TOMCAT_HOME/lib as well. However, this would cause conflicts becase Log4j >would no longer be running in its own "Log4j Universe". > >So, in a manner of speaking, my libraries are being held hostage in >WEB-INF/lib because Log4j is designed in a way that it needs to live on >it's own and not be shared by multiple apps at once. > >Have I interpreted things wrong, or is this what was intended? Is there >anything I can do to keep my libraries from being "held hostage"? Are >there any tricks that I'm missing here? > >Jake -- Ceki SUICIDE BOMBING - A CRIME AGAINST HUMANITY Sign the petition: http://www.petitiononline.com/1234567b I am signatory number 22106. What is your number? -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
