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: No Host matches server name localhost error
Try renaming the context.xml to ROOT.xml, I normally get the 400 error if it can't find the context for a particular path. For some reason Tomcat tends to ignore the path on the context. Paul On Tue, 2005-08-30 at 09:50 -0700, Brian Moseley wrote: i'm using tomcat 5.5.9 with a single webapp deployed with a context path of and a default host named localhost. when i request the webapp's root resource (http://localhost:8080/), i get a 400 error with the message No Host matches server name localhost. as you can see from my very minimal server.xml, i do in fact have a Host named localhost and have specified it as the default host for the engine. so, i must admit to being confused as to why i'm receiving that particular error message. :) i have turned on debug logging to verify that the context is being loaded, but i have yet to step through a request with a debugger. any ideas? server.xml: Server port=8005 shutdown=SHUTDOWN Service name=Catalina Connector port=8080 enableLookups=false/ Engine name=Catalina defaultHost=localhost Host name=localhost appBase=webapps autoDeploy=false/ /Engine /Service /Server context.xml (in conf/Catalina/localhost/): Context path= docBase=cosmo reloadable=true Environment name=cosmo/version value=0.2-4 type=java.lang.String override=false/ Environment name=cosmo/serverAdmin value=[EMAIL PROTECTED] type=java.lang.String override=false/ Environment name=cosmo/repository/username value=cosmo_repository type=java.lang.String override=false/ Environment name=cosmo/repository/password value= type=java.lang.String override=false/ Resource name=jcr/cosmo type=javax.jcr.Repository factory=org.apache.jackrabbit.core.jndi.BindableRepositoryFactory configFilePath=etc/repository.xml repHomeDir=data/repository/ Resource name=jdbc/cosmo type=javax.sql.DataSource maxActive=5 maxIdle=3 maxWait=1 username=sa parameter= driverClassName=org.hsqldb.jdbcDriver url=jdbc:hsqldb:file:data/db/userdb/ Resource name=mail/cosmo type=javax.mail.Session mail.transport.protocol=smtp/ mail.smtp.host=localhost/ mail.smtps.host=localhost/ mail.smtp.starttls.enable=false/ Valve className=org.apache.catalina.valves.AccessLogValve directory=../logs prefix=access. suffix=.log pattern=combined resolveHosts=false/ /Context - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: No Host matches server name localhost error
On Tue, 2005-08-30 at 13:25 -0500, Caldarale, Charles R wrote: From: Brian Moseley [mailto:[EMAIL PROTECTED] Subject: Re: No Host matches server name localhost error thanks for the pointer. after moving my context definition into server.xml Bad move. This is specifically discouraged in 5.5. It seems that Tomcat 5.5 discourages you from putting contexts in the server.xml, and that is something that is a good idea as it's easier to manage them when they are outside. But the context path is only supported when you put it in the server.xml so you can't deploy the wars to any other path other than the name of the context file so deploying to /apps/admin. I know there is the special ROOT.xml for the root context but that doesn't solve the sub path issue which no one seems to know the answer to. i wonder what the motivation was for making it such that i can't configure the root context in its own file? As far as I know, you can - just put your default context in webapps/ROOT, and its associated Context element in webapps/ROOT/META-INF/context.xml. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - 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]
Re: Automatic deploy of updated war deletes the context file
The test case I am using is running on Tomcat 5.5.9. 1. The web application is deployed as a the app.war file, with no context.xml file to the wars/host directory 2. The Host configuration is as follows. Host debug=99 name=host unpackWARs=false deployXML=false Logger className=org.apache.catalina.logger.FileLogger prefix=host timestamp=false / /Host 3. In conf/Catalina/host/app.xml ?xml version='1.0' encoding='utf-8'? Context debug=9 docBase=wars/host/app.war path=/app reloadable=true workDir=work/Catalina/host/app ResourceLink global=jdbc/appDs name=jdbc/appDs type=javax.sql.DataSource/ /Context When I copy app.war into wars/host to repeploy using the automatic deployer I check the conf/Catalina/host/ and http://host/manager/list and the app.xml and the /app context are deleted. On Thu, 2005-08-25 at 16:32 -0700, Hassan Schroeder wrote: Paul Austin wrote: Right but where should it go so that tomcat doesn't delete it? I've tried setting the deployXML=false on the host and having it just in the conf/Catalina/host directory (which is my preferred location), just in the war file and all various combinations. I've used both locations -- separately! -- without problems. Are you saying that with *only* /conf/Catalina/host/context.xml, nothing in META-INF/context.xml, your deployment fails and the context.xml file is removed? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Automatic deploy of updated war deletes the context file
I know almost have it 'The way I want it to work (TM)' using the following configuration. - server.xml Host appBase=wars/host autoDeploy=false debug=99 name=host unpackWARs=false deployXML=false Logger className=org.apache.catalina.logger.FileLogger prefix=host timestamp=false / /Host - conf/Catalina/host/app.xml ?xml version='1.0' encoding='utf-8'? Context debug=9 docBase=app-web.war path=/app reloadable=true ResourceLink global=jdbc/appDs name=jdbc/appDs type=javax.sql.DataSource / /Context Now the final question is how can I set the path to be a sub directory? So /subdir/app. This worked on my Tomcat 5 installation on Linux but doesn't work here. It seems to just ignore the path. And YES these context files are NOT deployed as part of the war file. On Fri, 2005-08-26 at 08:33 -0700, Hassan Schroeder wrote: Paul Austin wrote: The test case I am using is running on Tomcat 5.5.9. 1. The web application is deployed as a the app.war file, with no context.xml file to the wars/host directory _and_ no META-INF/context.xml in the war file, right? 2. The Host configuration is as follows. Host debug=99 name=host unpackWARs=false deployXML=false Logger className=org.apache.catalina.logger.FileLogger prefix=host timestamp=false / /Host 3. In conf/Catalina/host/app.xml ?xml version='1.0' encoding='utf-8'? Context debug=9 docBase=wars/host/app.war path=/app reloadable=true workDir=work/Catalina/host/app ResourceLink global=jdbc/appDs name=jdbc/appDs type=javax.sql.DataSource/ /Context When I copy app.war into wars/host to repeploy using the automatic deployer I check the conf/Catalina/host/ and http://host/manager/list and the app.xml and the /app context are deleted. I would check your logs for errors, but also go through all your entries in your server.xml and app.xml files For instance, for the path attribute of Context: The value of this field must not be set except when statically defining a Context in server.xml, as it will be infered from the filenames used for either the .xml context file or the docBase. Sometimes the subtle config errors will bite'cha :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Deploying war applications under a sub directory
I'm trying to deploy a war based web application to tomcat 5.5.9 on Windows XP JDK 1.4.2 and am experiencing problems with the deployment when the application path includes a sub directory before the application directory (e.g. /subdir/app instead of /app). When deploying to /app (with the appropriate changes to context.xml) I can access the application via http://myhost/app and also start/stop/undeploy etc it via the http://myhost/manager. When I try to deploy to /subdir/app it can deploy but then you can't start/stop it or access it via http://myhost/subdir/app which returns a 400 No server error. Has anyone else had any success in doing this in 5.5.9, I had it working in 5.0 on Linux. The host definition in server.xml is as follows: Host debug=99 name=myhost unpackWARs=false deployXML=true Logger className=org.apache.catalina.logger.FileLogger prefix=secure timestamp=false / /Host The context.xml definition deployed in the app.war and also manually copied to conf/Catalina/myhost/app.xml. ?xml version='1.0' encoding='utf-8'? Context debug=9 docBase=wars/myhost/app.war path=/subdir/app reloadable=true workDir=work/Catalina/myhost/app ResourceLink global=jdbc/appDs name=jdbc/appDs type=javax.sql.DataSource / /Context - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Automatic deploy of updated war deletes the context file
When I copy an updated copy of a war file that was deployed with a context.xml file in the META-INF directory and also I have a copy of the context.xml in the conf/Catalina/host directory the deployer just deletes the context altogether and doesn't reploy the application. How is this supposed to work, the only guess I can have as to why this doesn't work is that tomcat detects the file change half way through the file is being copied, undeploys the old application deleting the context file and then barfs on reading the half copied war file and just gives up and there is nothing in the logs to say what is going on. The way I fix this is to then manually copy in the context file and then it deploys, for now I'm just going to wait about 10 seconds in my ant deploy script after copying the file and then copy the context in so it redeploys. Paul
Re: Automatic deploy of updated war deletes the context file
Right but where should it go so that tomcat doesn't delete it? I've tried setting the deployXML=false on the host and having it just in the conf/Catalina/host directory (which is my preferred location), just in the war file and all various combinations. Paul On Thu, 2005-08-25 at 15:44 -0700, Hassan Schroeder wrote: So Paul Austin says: Doctor, When I copy an updated copy of a war file that was deployed with a context.xml file in the META-INF directory and also I have a copy of the context.xml in the conf/Catalina/host directory the deployer just deletes the context altogether and doesn't reploy the application. ..and the Doctor says: Right, so don't do that. /* Heh. Vaudeville :-) */ Seriously, you only want to have your Context defined *one* place.
