Caldarale, Charles R wrote:
Once you have your test Tomcat set up on the problematic server, try adding
this line to the conf/logging.properties file:
org.apache.jasper.level = ALL
That will display a *lot* of information about what's going on during JSP
compilation. One thing in particular printed out during Tomcat initialization
is the compiler classpath for JSPs in each webapp, which might show why the
lookups are being done at the root of the file system.
OK, done. I started up my test instance, ran a single request on my test JSP,
and shut it down. The resulting
catalina.out is here for your review:
http://ims.net/media/jasper-level-all.txt
Sure enough, / appears in the classpath for the ROOT webapp, right here:
[stuff]:/usr/local/lib/jtds-1.2.2.jar:/:/usr/local/tomcat-2/bin/bootstrap.jar:[other
stuff]
/ is appended after a jar that I have symlinked under $TOMCAT_HOME/lib and
before bootstrap.jar.
So, SINCE my company is ims.net and my Java packages start with net.ims; and
SINCE I had autofs running which
automounted /net; and SINCE / is in the classpath, JDT searched under /net to
find core classes, which incurred a very
long delay, presumably due to automount. If autofs is off and /net is simply
an empty directory, the delay is not
incurred. My problem is cured by simply turning off autofs.
It seems to me that it's a bug that / is being appended to the classpath, but
one that didn't result in pain until the
particular circumstance above came into play, clearly a VERY specific scenario.
THANKS, EVERYONE! I think we've solved this riddle! I owe you all beers, or
your beverage of choice!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
