tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 22478] - Ant manager deploy causing webapp to initialize twice
Date Sat, 16 Aug 2003 15:24:23 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22478>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22478

Ant manager deploy causing webapp to initialize twice





------- Additional Comments From hoju@visi.com  2003-08-16 15:24 -------
>The bug, if there's one, is maybe that your context XML should be removed on
>undeploy. This works fine for me (the WAR, expanded dir, and expanded XML are
>all removed on undeploy, as long as their names match).

My context configuration file (ccf) and everything else is removed just fine
upon undeploy.  I've verified this many times.  Also, Tomcat creates the ccf
from the one I supply in the .war file; META-INF/context.xml.  I assume that is
still correct to do with Tomcat5, right?  That's the way Tomcat4.1.xx worked. 
It must be right because it seems to extract it to the appropriate place and use it.

Besides, given that with a virgin Tomcat server and my app never having been
deployed there before, I still get exceptions upon the first deploy shown in the
stacktrace in the log file I attached.  Did you have a look at that yet?
http://nagoya.apache.org/bugzilla/showattachment.cgi?attach_id=7843

This doesn't happen if I physically place the application there before Tomcat
has ever been started.  It only happens upon a manager app deployment, so I
think that pretty clearly implicates the manager application or some process it
uses.

>As for the "CL stopped" exception, well, log4j shouldn't have watchdog threads
>or similar stuff (or you should destroy your loggers manually when your
>application is stopped).

I actually do manually shutdown Log4j when the application is stopped...

See for yourself here...
http://cvs.apache.org/viewcvs/jakarta-log4j-sandbox/src/java/org/apache/log4j/servlet/InitContextListener.java?rev=1.7&content-type=text/vnd.viewcvs-markup

Here's the relevant code from there...

public void contextDestroyed(ServletContextEvent sce) {
    ServletContext context = sce.getServletContext();

    cleanupLog4j(context);
}

private void cleanupLog4j(ServletContext context) {
    //shutdown this webapp's logger repository
    context.log(
      "Cleaning up Log4j resources for context: "
      + context.getServletContextName() + "...");
    context.log("Shutting down all loggers and appenders...");
    org.apache.log4j.LogManager.shutdown();
    context.log("Log4j cleaned up.");
}

Either way, the watchdog is in the process of configuring itself at startup. 
How is this a shutdown issue?  Additionally, although Log4j involved in the
stack trace, it doesn't seem to be the cause of the issue.  These are the lines
of significance...

java.lang.IncompatibleClassChangeError:
org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
	at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1251)

Please explain to me how the Log4j watchdog is responsible for an
IncompatibleClassChangeError in org.apache.xerces.jaxp.DocumentBuilderFactoryImpl?

And then, of course, there is the issue which I don't believe you addressed at
all which is the fact that the contextInitialized() in my servlet context
listener is running twice every time I do a deploy after an undeploy.


I'll leave this bug invalid for now, but I don't believe that is the case.  I
don't see where I am doing anything wrong?  Tomcat should be able to deal with
this deployment just fine, but it isn't.

Jake

Mime
View raw message