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 [EMAIL PROTECTED] 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
