tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 48097] NoClassDefFoundError on first access of first jsp
Date Mon, 02 Nov 2009 01:20:59 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=48097

--- Comment #4 from Amichai <amichai2@amichais.net> 2009-11-01 17:20:57 UTC ---
The bug occurs both with access to '/' and to '/index.jsp', so that can be
ruled out as a cause.

I hope I understood you correctly - to make sure, here are the exact steps I
just did:
0. stopped the distro's tomcat instance, and verified there's nothing at
localhost:8080.
1. downloaded the tomcat 6.0.20 binary tar.gz distribution from
http://tomcat.apache.org/download-60.cgi, and extracted it to a temp folder.
2. renamed the webapps/ROOT app to webapps/ROOT.original, and copied the ROOT
app (the attachment to this bug) in its place.
3. ran './catalina.sh start -security' from the bin directory.
4. opened localhost:8080/index.jsp in the browser. the page loaded
successfully.
5. I realized the classloading was behaving differently than before since there
are other webapps (the samples in the distribution, etc.). I backed up the
entire webapps folder to webapps.original, and then deleted all folders under
webapps, leaving only the ROOT folder (which is my sample app).
6. ran './catalina.sh stop', refreshed the browser to make sure the server is
down, followed by './catalina.sh start'.
7. refreshed the browser again - and the error was reproduced.
8. downloaded the catalina.policy file from
http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/conf/ and replaced the
conf/catalina.policy file with it.
9. did steps 6 and 7 again, and the error was reproduced again.
10. repeated steps 6 and 7 again a few more times, accessing either '/' or
'/index.jsp', changing the order of the jsp lines (as described in the original
report), etc. everything was reproduced exactly as in the original report.

So, in a nutshell, take the official tomcat binary unmodified, delete
everything in the webapps folder (which cause a different classloading sequence
to occur), put the attached ROOT sample app in there, and fire it up - this was
enough to fully reproduce the bug.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message