Pid said on 29.6.2010 13:36:
On 29/06/2010 11:51, Tomislav Petrović wrote:
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?
Not unless someone here says so. We haven't eliminated the possibility
of errors in the config files yet.
OK, which configuration (classpath, windows path, what?) is in question
here and has, possible extra, // at the end of string? Which parameter
should I hunt for?
--
Tomy <t.petro...@inet.hr>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
