Re: Tomcat 5.5 classloader log4j vs JCL issue
hihi Paul, i tried your suggestion but it still did not work. however, i finally found out why. the problem web application had the following code: try { System.setProperty(org.apache.commons.logging.Log, org.apache.commons.logging.impl.Log4JCategoryLog); } catch (java.security.AccessControlException e) { logCat.warn(Unable map commons-logging to Log4j, due to SecurityManager, e); } this piece of code seems like the ultimate way of setting the logging system. at least this was the effect it had in my case. (perhaps it was executed last... definitely after your listener code) in any case, once i commented out this bit of code everything was fine again, and i did not have to put the combination log4j.jar and commons-logging.jar into the ${Tomcat}/common/lib folder. i was able to place them in the relevant web app's WEB-INF/lib folder and my other web apps were undisturbed! yay! :) thanks again for your help, Paul! woodchuck --- Paul Austin [EMAIL PROTECTED] wrote: Woodchuck, The following web page describes this situation and a solution to the problem. http://www.qos.ch/logging/sc.jsp I have attached the solution that I created this week based on the information above. To compile you will need servlet-api.jar and log4j.jar to compile. Include the jar you create from these files in your web application and then in your web.xml include the following sections. This section can be used if your log4j.xml is not under /WEB-INF/log4j.xml context-param param-namelog4jXmlLocation/param-name param-value/WEB-INF/log4j.xml/param-value /context-param The following calls invokes the listerner when the web app starts up to create a separate logging context for the web application. listener listener-classcom.revolsys.logging.log4j.Log4jServletContextListener/listener-class /listener Also make sure you have a listener that does the following when the context is destroyed otherwise you'll get a log of PermGen out of memory errors after a number of redeploys Introspector.flushCaches(); LogFactory.getFactory().release(); Good luck, Paul On Wed, 2005-08-31 at 13:03 -0700, Woodchuck wrote: hihi all, on my TC 5.5.9 installation i deployed several web applications that uses the default JCL logging. that is, i placed a simple logging.properties file into each web app's WEB-INF/classes folder and i have per web app logging. everything works beautifully. then i installed a new web app that forced me to place commons-logging.jar and log4j.jar into the ${Tomcat}/common/lib folder. as a result, all my previous per web app logging no longer works. i believe this is because log4j was discovered in the ${Tomcat}/common/lib first, and therefore it has superceeded any other logging system at the (lower) web app level. this is due to Tomcat's classloading process. the reason this new web app required commons-logging.jar and log4j.jar to be placed specifically into the ${Tomcat}/commons/lib folder is because it instantiates a log4j logger object in it's start-up servlet which extends HttpServlet which is found in the servlet-api.jar which is also in the ${Tomcat}/commons/lib folder. this is because Tomcat's classloading hierarchy dictates that classes in the common/lib cannot see web app classes 'downstream'. does anyone have any suggestions on how i can have per web app logging again? i would like to keep my deployment process as web app isolated as possible (ie. each web app deployed by WAR, drop it in and that's it, no further steps necessary). thanks in advance, woodchuck Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] /* * Copyright 2005 Revolution Systems Inc. * * Licensed under the Apache License, Version 2.0 (the License); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an AS IS BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */ package com.revolsys.logging.log4j; import java.util.HashMap; import java.util.Map; import org.apache.log4j.Hierarchy; import org.apache.log4j.Level; import org.apache.log4j.LogManager; import org.apache.log4j.spi.LoggerRepository; import
RE: Tomcat 5.5 classloader log4j vs JCL issue
hihi Seva, yes, your suggestion also works. i tried it to confirm, and it was my backup plan to do in case i couldn't figure out how to *not* place log4j.jar and commons-logging.jar into the ${Tomcat}/common/lib folder. just fyi, it's also possible to centralize logging for the entire servlet container by having the log4j.properties file in ${Tomcat}/common/classes (and the log4j.jar in ${Tomcat}/common/lib). this way, it is not necessary to put log4j.jar in each web app's WEB-INF/lib folder, nor the log4j.properties file in each web app's WEB-INF/classes folder. centralize, as in one log4j.properties file and one log4j.jar file. yet, Tomcat and each web app can still maintain their own separate log files! i've tested this and it works as well. woodchuck --- Seva Popov [EMAIL PROTECTED] wrote: Woodchuck, I guess, the alternative solution is to have all your web apps use log4j as well. So, you have commons-logging.jar and log4j.jar in the ${Tomcat}/common/lib folder and log4j.properties in ${Tomcat}/common/classes folder. Just add into your each web app's WEB-INF/classes folder log4j.properties file and into WEB-INF/lib folder log4j.jar. This way both Tomcat and your web apps will use separate log4j configurations. Thanks, Seva From: Paul Austin [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 31, 2005 1:30 PM To: Tomcat Users List Subject: Re: Tomcat 5.5 classloader log4j vs JCL issue Woodchuck, The following web page describes this situation and a solution to the problem. http://www.qos.ch/logging/sc.jsp I have attached the solution that I created this week based on the information above. To compile you will need servlet-api.jar and log4j.jar to compile. Include the jar you create from these files in your web application and then in your web.xml include the following sections. This section can be used if your log4j.xml is not under /WEB-INF/log4j.xml context-param param-namelog4jXmlLocation/param-name param-value/WEB-INF/log4j.xml/param-value /context-param The following calls invokes the listerner when the web app starts up to create a separate logging context for the web application. listener listener-classcom.revolsys.logging.log4j.Log4jServletContextListener/ listener-class /listener Also make sure you have a listener that does the following when the context is destroyed otherwise you'll get a log of PermGen out of memory errors after a number of redeploys Introspector.flushCaches(); LogFactory.getFactory().release(); Good luck, Paul On Wed, 2005-08-31 at 13:03 -0700, Woodchuck wrote: hihi all, on my TC 5.5.9 installation i deployed several web applications that uses the default JCL logging. that is, i placed a simple logging.properties file into each web app's WEB-INF/classes folder and i have per web app logging. everything works beautifully. then i installed a new web app that forced me to place commons-logging.jar and log4j.jar into the ${Tomcat}/common/lib folder. as a result, all my previous per web app logging no longer works. i believe this is because log4j was discovered in the ${Tomcat}/common/lib first, and therefore it has superceeded any other logging system at the (lower) web app level. this is due to Tomcat's classloading process. the reason this new web app required commons-logging.jar and log4j.jar to be placed specifically into the ${Tomcat}/commons/lib folder is because it instantiates a log4j logger object in it's start-up servlet which extends HttpServlet which is found in the servlet-api.jar which is also in the ${Tomcat}/commons/lib folder. this is because Tomcat's classloading hierarchy dictates that classes in the common/lib cannot see web app classes 'downstream'. does anyone have any suggestions on how i can have per web app logging again? i would like to keep my deployment process as web app isolated as possible (ie. each web app deployed by WAR, drop it in and that's it, no further steps necessary). thanks in advance, woodchuck Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Click here to donate to the Hurricane Katrina relief effort. http://store.yahoo.com/redcross-donate3/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 5.5 classloader log4j vs JCL issue
Yes it it possible to centralize the logging for the entire container including all web apps. However, this seems to be a bad practice. The better approach is to separate the container internal logging and the web apps logging. But I guess you know this for yourself. -Original Message- From: Woodchuck [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 06, 2005 11:10 AM To: Tomcat Users List; Seva Popov Subject: RE: Tomcat 5.5 classloader log4j vs JCL issue hihi Seva, yes, your suggestion also works. i tried it to confirm, and it was my backup plan to do in case i couldn't figure out how to *not* place log4j.jar and commons-logging.jar into the ${Tomcat}/common/lib folder. just fyi, it's also possible to centralize logging for the entire servlet container by having the log4j.properties file in ${Tomcat}/common/classes (and the log4j.jar in ${Tomcat}/common/lib). this way, it is not necessary to put log4j.jar in each web app's WEB-INF/lib folder, nor the log4j.properties file in each web app's WEB-INF/classes folder. centralize, as in one log4j.properties file and one log4j.jar file. yet, Tomcat and each web app can still maintain their own separate log files! i've tested this and it works as well. woodchuck --- Seva Popov [EMAIL PROTECTED] wrote: Woodchuck, I guess, the alternative solution is to have all your web apps use log4j as well. So, you have commons-logging.jar and log4j.jar in the ${Tomcat}/common/lib folder and log4j.properties in ${Tomcat}/common/classes folder. Just add into your each web app's WEB-INF/classes folder log4j.properties file and into WEB-INF/lib folder log4j.jar. This way both Tomcat and your web apps will use separate log4j configurations. Thanks, Seva From: Paul Austin [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 31, 2005 1:30 PM To: Tomcat Users List Subject: Re: Tomcat 5.5 classloader log4j vs JCL issue Woodchuck, The following web page describes this situation and a solution to the problem. http://www.qos.ch/logging/sc.jsp I have attached the solution that I created this week based on the information above. To compile you will need servlet-api.jar and log4j.jar to compile. Include the jar you create from these files in your web application and then in your web.xml include the following sections. This section can be used if your log4j.xml is not under /WEB-INF/log4j.xml context-param param-namelog4jXmlLocation/param-name param-value/WEB-INF/log4j.xml/param-value /context-param The following calls invokes the listerner when the web app starts up to create a separate logging context for the web application. listener listener-classcom.revolsys.logging.log4j.Log4jServletContextListener/ listener-class /listener Also make sure you have a listener that does the following when the context is destroyed otherwise you'll get a log of PermGen out of memory errors after a number of redeploys Introspector.flushCaches(); LogFactory.getFactory().release(); Good luck, Paul On Wed, 2005-08-31 at 13:03 -0700, Woodchuck wrote: hihi all, on my TC 5.5.9 installation i deployed several web applications that uses the default JCL logging. that is, i placed a simple logging.properties file into each web app's WEB-INF/classes folder and i have per web app logging. everything works beautifully. then i installed a new web app that forced me to place commons-logging.jar and log4j.jar into the ${Tomcat}/common/lib folder. as a result, all my previous per web app logging no longer works. i believe this is because log4j was discovered in the ${Tomcat}/common/lib first, and therefore it has superceeded any other logging system at the (lower) web app level. this is due to Tomcat's classloading process. the reason this new web app required commons-logging.jar and log4j.jar to be placed specifically into the ${Tomcat}/commons/lib folder is because it instantiates a log4j logger object in it's start-up servlet which extends HttpServlet which is found in the servlet-api.jar which is also in the ${Tomcat}/commons/lib folder. this is because Tomcat's classloading hierarchy dictates that classes in the common/lib cannot see web app classes 'downstream'. does anyone have any suggestions on how i can have per web app logging again? i would like to keep my deployment process as web app isolated as possible (ie. each web app deployed by WAR, drop it in and that's it, no further steps necessary). thanks in advance, woodchuck Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
Tomcat 5.5 classloader log4j vs JCL issue
I'm having the same issue and after trying to follow the instructions given by Paul Austin, I've got stuck on the part that says to add a listener. There's no place for a listener in web.xml according to the dtd validation file. Am I wrong ? (I'm using Tomcat 5.5.9 with the struts framework) Everything else went fine. I've created a jar file with your source code. BTW, where am I supposed to put this jar anyways ? in common/lib/ ?? And just to double check, is this log4j.xml file valid ? : --- ?xml version=1.0 encoding=UTF-8 ? !-- !DOCTYPE log4j:configuration SYSTEM log4j.dtd -- log4j:configuration xmlns:log4j=http://jakarta.apache.org/log4j/; appender name=ConsoleAppender class=org.apache.log4j.ConsoleAppender layout class=org.apache.log4j.SimpleLayout/ /appender root priority value =debug / appender-ref ref=ConsoleAppender/ /root /log4j:configuration --- Thanks a lot Luc Boudreau SID - Université du Québec [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5 classloader log4j vs JCL issue
Luc, The listener element is only valid in the Servlet 2.3 web.xml file, if using a previous servlet version use the attached servlet set to load at startup before any of the other servlets. The jar containing my classes should be included in your WEB-INF/lib directory in each web application. Paul On Fri, 2005-09-02 at 09:07 -0400, [EMAIL PROTECTED] wrote: I'm having the same issue and after trying to follow the instructions given by Paul Austin, I've got stuck on the part that says to add a listener. There's no place for a listener in web.xml according to the dtd validation file. Am I wrong ? (I'm using Tomcat 5.5.9 with the struts framework) Everything else went fine. I've created a jar file with your source code. BTW, where am I supposed to put this jar anyways ? in common/lib/ ?? And just to double check, is this log4j.xml file valid ? : --- ?xml version=1.0 encoding=UTF-8 ? !-- !DOCTYPE log4j:configuration SYSTEM log4j.dtd -- log4j:configuration xmlns:log4j=http://jakarta.apache.org/log4j/; appender name=ConsoleAppender class=org.apache.log4j.ConsoleAppender layout class=org.apache.log4j.SimpleLayout/ /appender root priority value =debug / appender-ref ref=ConsoleAppender/ /root /log4j:configuration --- Thanks a lot Luc Boudreau SID - Université du Québec [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] /* * Copyright 2005 Revolution Systems Inc. * * Licensed under the Apache License, Version 2.0 (the License); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an AS IS BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */ package com.revolsys.logging.log4j; import java.io.InputStream; import javax.servlet.ServletConfig; import javax.servlet.ServletContext; import javax.servlet.ServletException; import javax.servlet.http.HttpServlet; import org.apache.log4j.Hierarchy; import org.apache.log4j.xml.DOMConfigurator; /** * The Log4jInitializationServlet class uses the * [EMAIL PROTECTED] ContextClassLoaderRepositorySelector} to maintain a separate Log4j * configuration for a servlet context and to load the logging configuration * from the log4j.xml file specified by the log4jXmlLocation context-param (or * /WEB-INF/log4j.xml if not specified). * * @author Paul Austin * @version 1.0 */ public class Log4jInitializationServlet extends HttpServlet { /** The default location for the log4j.xml file. */ public static final String DEFAULT_LOG4J_XML_LOCATION = /WEB-INF/log4j.xml; /** * Initialize the logging for context by creating a new heirarchy for the * current thread context class context and loading the configuration from * the log4jXmlLocation context-param. * * @param config The servlet configuration. * @throws ServletException If there was a problem initializing the servlet. */ public void init(final ServletConfig config) throws ServletException { super.init(config); Hierarchy hierarchy = ContextClassLoaderRepositorySelector.add(); ServletContext context = config.getServletContext(); String log4jXml = context.getInitParameter(log4jXmlLocation); if (log4jXml == null) { log4jXml = DEFAULT_LOG4J_XML_LOCATION; } try { InputStream log4JConfig = context.getResourceAsStream(log4jXml); if (log4JConfig != null) { DOMConfigurator conf = new DOMConfigurator(); conf.doConfigure(log4JConfig, hierarchy); } } catch (Exception e) { throw new ServletException(e); } } /** * Clean up the servlet by removing the logging configuration for the * current context. */ public void destroy() { ContextClassLoaderRepositorySelector.remove(); } } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat 5.5 classloader log4j vs JCL issue
hihi all, on my TC 5.5.9 installation i deployed several web applications that uses the default JCL logging. that is, i placed a simple logging.properties file into each web app's WEB-INF/classes folder and i have per web app logging. everything works beautifully. then i installed a new web app that forced me to place commons-logging.jar and log4j.jar into the ${Tomcat}/common/lib folder. as a result, all my previous per web app logging no longer works. i believe this is because log4j was discovered in the ${Tomcat}/common/lib first, and therefore it has superceeded any other logging system at the (lower) web app level. this is due to Tomcat's classloading process. the reason this new web app required commons-logging.jar and log4j.jar to be placed specifically into the ${Tomcat}/commons/lib folder is because it instantiates a log4j logger object in it's start-up servlet which extends HttpServlet which is found in the servlet-api.jar which is also in the ${Tomcat}/commons/lib folder. this is because Tomcat's classloading hierarchy dictates that classes in the common/lib cannot see web app classes 'downstream'. does anyone have any suggestions on how i can have per web app logging again? i would like to keep my deployment process as web app isolated as possible (ie. each web app deployed by WAR, drop it in and that's it, no further steps necessary). thanks in advance, woodchuck Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5 classloader log4j vs JCL issue
Woodchuck, The following web page describes this situation and a solution to the problem. http://www.qos.ch/logging/sc.jsp I have attached the solution that I created this week based on the information above. To compile you will need servlet-api.jar and log4j.jar to compile. Include the jar you create from these files in your web application and then in your web.xml include the following sections. This section can be used if your log4j.xml is not under /WEB-INF/log4j.xml context-param param-namelog4jXmlLocation/param-name param-value/WEB-INF/log4j.xml/param-value /context-param The following calls invokes the listerner when the web app starts up to create a separate logging context for the web application. listener listener-classcom.revolsys.logging.log4j.Log4jServletContextListener/listener-class /listener Also make sure you have a listener that does the following when the context is destroyed otherwise you'll get a log of PermGen out of memory errors after a number of redeploys Introspector.flushCaches(); LogFactory.getFactory().release(); Good luck, Paul On Wed, 2005-08-31 at 13:03 -0700, Woodchuck wrote: hihi all, on my TC 5.5.9 installation i deployed several web applications that uses the default JCL logging. that is, i placed a simple logging.properties file into each web app's WEB-INF/classes folder and i have per web app logging. everything works beautifully. then i installed a new web app that forced me to place commons-logging.jar and log4j.jar into the ${Tomcat}/common/lib folder. as a result, all my previous per web app logging no longer works. i believe this is because log4j was discovered in the ${Tomcat}/common/lib first, and therefore it has superceeded any other logging system at the (lower) web app level. this is due to Tomcat's classloading process. the reason this new web app required commons-logging.jar and log4j.jar to be placed specifically into the ${Tomcat}/commons/lib folder is because it instantiates a log4j logger object in it's start-up servlet which extends HttpServlet which is found in the servlet-api.jar which is also in the ${Tomcat}/commons/lib folder. this is because Tomcat's classloading hierarchy dictates that classes in the common/lib cannot see web app classes 'downstream'. does anyone have any suggestions on how i can have per web app logging again? i would like to keep my deployment process as web app isolated as possible (ie. each web app deployed by WAR, drop it in and that's it, no further steps necessary). thanks in advance, woodchuck Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] /* * Copyright 2005 Revolution Systems Inc. * * Licensed under the Apache License, Version 2.0 (the License); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an AS IS BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */ package com.revolsys.logging.log4j; import java.util.HashMap; import java.util.Map; import org.apache.log4j.Hierarchy; import org.apache.log4j.Level; import org.apache.log4j.LogManager; import org.apache.log4j.spi.LoggerRepository; import org.apache.log4j.spi.RepositorySelector; import org.apache.log4j.spi.RootCategory; /** * The ContextClassLoaderRepositorySelector class is used to manage different * [EMAIL PROTECTED] LoggerRepository} heirarchies for different context class loaders. The * [EMAIL PROTECTED] #add()} method can be used to create a seperate logger repository for * the current thread context class loader. When the class loader is about to be * destroyed use the [EMAIL PROTECTED] #remove()} method to clean up the logger repository * for the class loader. See the [EMAIL PROTECTED] Log4jServletContextListener} for use in * web applications. * * @author Paul Austin * @version 1.0 */ public class ContextClassLoaderRepositorySelector implements RepositorySelector { /** The gaurd used to set the respository selector on the LogManager. */ private static final Object GUARD = LogManager.getRootLogger(); /** The map of class loaders to logging hierarchies. */ private static final Map repositories = new HashMap(); /** * The deault repository to use when one hasn't been created for the class * loader. */ private static final LoggerRepository defaultRepository; static { defaultRepository = LogManager.getLoggerRepository();
Re: Tomcat 5.5 classloader log4j vs JCL issue
From: Woodchuck [EMAIL PROTECTED] then i installed a new web app that forced me to place commons-logging.jar and log4j.jar into the ${Tomcat}/common/lib folder. as a result, all my previous per web app logging no longer works. does anyone have any suggestions on how i can have per web app logging again? i would like to keep my deployment process as web app isolated as possible (ie. each web app deployed by WAR, drop it in and that's it, no further steps necessary). Is giving the uncooperative webapp its own Tomcat instance an option? That's what I'd do. I have a third-party app that insists on all kinds of special configuration. I maintain the project as an expanded directory structure that overlays a Tomcat install. -- Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5 classloader log4j vs JCL issue
hihi Paul, thanks so much for your help! i will definitely give this a try and post my results. woodchuck --- Paul Austin [EMAIL PROTECTED] wrote: Woodchuck, The following web page describes this situation and a solution to the problem. http://www.qos.ch/logging/sc.jsp I have attached the solution that I created this week based on the information above. To compile you will need servlet-api.jar and log4j.jar to compile. Include the jar you create from these files in your web application and then in your web.xml include the following sections. This section can be used if your log4j.xml is not under /WEB-INF/log4j.xml context-param param-namelog4jXmlLocation/param-name param-value/WEB-INF/log4j.xml/param-value /context-param The following calls invokes the listerner when the web app starts up to create a separate logging context for the web application. listener listener-classcom.revolsys.logging.log4j.Log4jServletContextListener/listener-class /listener Also make sure you have a listener that does the following when the context is destroyed otherwise you'll get a log of PermGen out of memory errors after a number of redeploys Introspector.flushCaches(); LogFactory.getFactory().release(); Good luck, Paul Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 5.5 classloader log4j vs JCL issue
Woodchuck, I guess, the alternative solution is to have all your web apps use log4j as well. So, you have commons-logging.jar and log4j.jar in the ${Tomcat}/common/lib folder and log4j.properties in ${Tomcat}/common/classes folder. Just add into your each web app's WEB-INF/classes folder log4j.properties file and into WEB-INF/lib folder log4j.jar. This way both Tomcat and your web apps will use separate log4j configurations. Thanks, Seva From: Paul Austin [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 31, 2005 1:30 PM To: Tomcat Users List Subject: Re: Tomcat 5.5 classloader log4j vs JCL issue Woodchuck, The following web page describes this situation and a solution to the problem. http://www.qos.ch/logging/sc.jsp I have attached the solution that I created this week based on the information above. To compile you will need servlet-api.jar and log4j.jar to compile. Include the jar you create from these files in your web application and then in your web.xml include the following sections. This section can be used if your log4j.xml is not under /WEB-INF/log4j.xml context-param param-namelog4jXmlLocation/param-name param-value/WEB-INF/log4j.xml/param-value /context-param The following calls invokes the listerner when the web app starts up to create a separate logging context for the web application. listener listener-classcom.revolsys.logging.log4j.Log4jServletContextListener/ listener-class /listener Also make sure you have a listener that does the following when the context is destroyed otherwise you'll get a log of PermGen out of memory errors after a number of redeploys Introspector.flushCaches(); LogFactory.getFactory().release(); Good luck, Paul On Wed, 2005-08-31 at 13:03 -0700, Woodchuck wrote: hihi all, on my TC 5.5.9 installation i deployed several web applications that uses the default JCL logging. that is, i placed a simple logging.properties file into each web app's WEB-INF/classes folder and i have per web app logging. everything works beautifully. then i installed a new web app that forced me to place commons-logging.jar and log4j.jar into the ${Tomcat}/common/lib folder. as a result, all my previous per web app logging no longer works. i believe this is because log4j was discovered in the ${Tomcat}/common/lib first, and therefore it has superceeded any other logging system at the (lower) web app level. this is due to Tomcat's classloading process. the reason this new web app required commons-logging.jar and log4j.jar to be placed specifically into the ${Tomcat}/commons/lib folder is because it instantiates a log4j logger object in it's start-up servlet which extends HttpServlet which is found in the servlet-api.jar which is also in the ${Tomcat}/commons/lib folder. this is because Tomcat's classloading hierarchy dictates that classes in the common/lib cannot see web app classes 'downstream'. does anyone have any suggestions on how i can have per web app logging again? i would like to keep my deployment process as web app isolated as possible (ie. each web app deployed by WAR, drop it in and that's it, no further steps necessary). thanks in advance, woodchuck Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5 classloader log4j vs JCL issue
hihi Wendy, hehe. that also crossed my mind, i wish that was an option, but i can't unfortunately.:) woodchuck --- Wendy Smoak [EMAIL PROTECTED] wrote: Is giving the uncooperative webapp its own Tomcat instance an option? That's what I'd do. I have a third-party app that insists on all kinds of special configuration. I maintain the project as an expanded directory structure that overlays a Tomcat install. -- Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]