Tomislav Petrović said on 28.6.2010 15:46: > Caldarale, Charles R said on 28.6.2010 15:32: > >> Seems to me it is related to web app reloading but this > >> is my blind guess. > > > > What makes you suspicious that reloading is going on? > > > > Just my VERY BIG AND BLIND guess based on classes involved in stack trace. >
This is my "dissection" of problematic stacktrace using my limited Java knowledge and Tomcat sources. Stacktrace written in "reverse" way to follow code flow more easily. at java.lang.Thread.run(Thread.java:619) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1590) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1610) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1610) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1601) Background thread which periodically calls "backgroundProcess" on container and its children, I believe it is used to determine wether app needs to be reloaded (make sense to me that something periodically needs to check wether app needs to be reloaded). at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1309) at org.apache.catalina.loader.WebappLoader.backgroundProcess(WebappLoader.java:398) at org.apache.catalina.loader.WebappLoader.modified(WebappLoader.java:477) at org.apache.catalina.loader.WebappClassLoader.modified(WebappClassLoader.java:822) "modified" is called in order to find if "one or more classes or resources been modified so that a reload is appropriate?", at least that is what the JavaDoc comment says. at org.apache.naming.resources.ProxyDirContext.getAttributes(ProxyDirContext.java:840) at org.apache.naming.resources.BaseDirContext.getAttributes(BaseDirContext.java:747) at org.apache.naming.resources.FileDirContext.getAttributes(FileDirContext.java:429) Just forwards call to more appropriate classes up to here. at org.apache.naming.resources.FileDirContext.file(FileDirContext.java:811) Here a File object of "Return a File object representing the specified normalized context-relative path if it exists and is readable" is created, however name given to it chokes up "normalize", it seems. at org.apache.naming.resources.FileDirContext.normalize(FileDirContext.java:771) at org.apache.catalina.util.RequestUtil.normalize(RequestUtil.java:131) This is problematic code (part of normalize method): // Resolve occurrences of "//" in the normalized path while (true) { int index = normalized.indexOf("//"); if (index < 0) break; normalized = normalized.substring(0, index) + normalized.substring(index + 1); } Seems to me code assumes that if it founds "//" in a string then this "//" is not at the end of the string (has to have something behind it). In general case this sounds like a bug to me (however I am not expert here and don't know from where filename comes and how it should be written). So if anyone can tell me form where a name (filename) given to normalize comes (I assume it is something in classpath, configuration, path, or....?). So I can find it and remove (probably extra // or \) to solve my problem. And after I know what caused this, should this be reported as bug into Bugzilla? I'll give you server.xml and other conf as soon as I get them today. Thanks everyone, -- Tomy <t.petro...@inet.hr> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org