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