A couple months ago I had a slightly different setting but with the same
strange result - NoClassDefFoundErrors which occurred on a particular
jsp page in my app, but only if it was the first jsp accessed following
a restart (and remained in the error state until the next restart). If
it was not the first jsp accessed, then everything came up fine (with
nothing in the configuration or app changing in between). I also figured
it's some classloader bug in Tomcat, not entirely a race condition
(since it did happen consistently), but something that manifests itself
depending on the order of class loading.
I never did find out for sure what the problem was (maybe it's the sync
issue Mark refers to below), but I stumbled upon a workaround, which I
do not quite understand, which fixed this for good: I changed the order
of the first two statements in the jsp, the first was one that accessed
java.net.URI (a system class) and the second the session bean
declaration (a custom app-specific class). Although the two statements
were unrelated to each other and their order should not have made any
difference, this solved the problem (switching them back did reintroduce
the error, consistently). I still suspect the problem was with the order
of classloading.
So, not sure if this will help, but in the off chance that your issue is
related to the one I was experiencing, you might want to try fiddling
with the order in which classes are accessed/loaded by Tomcat (either
via their xml reference, or their actual content's first statements) and
hopefully something will work. Yes, it sounds strange, but it worked for
me in a reproducible manner.
Good luck :-)
Amichai
Mark Thomas wrote:
M4N - Arjan Tijms wrote:
I removed the obvious suspect, a duplicate postgresql driver that
appeared in both WEB-INF/lib and [tomcat install dir]/lib.
Unfortunately this did not seem to help. Last night I needed to restart
the production server for a configuration change and I needed 22(!)
restarts for Tomcat to start up correctly.
It really seems that there's a race condition going on somehow. I mean,
if it was a structural problem then Tomcat would simply never start up,
wouldn't it?
A reasonable conclusion.
The Jboss libraries are the Jboss client libraries and are needed to
consume EJBs from a remote Jboss AS instance. Maybe there are some
classes somewhere that conflict with those of Tomcat, but if that would
be true it's still hard to understand why starting up fails in
production but never on a local workstation.
Does the production box have more cores than the dev box? If there was a
race condition you would be more likely to see it with more cores.
Anyone has any idea?
There was a sync issue in the webappclassloader fixed in 6.0.19.
Although the symptoms were different, it might be worth trying 6.0.20.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
