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