Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
From: bugzilla@apache.org
To: dev@tomcat.apache.org
Subject: DO NOT REPLY [Bug 48097] NoClassDefFoundError on first access of
 first jsp
In-Reply-To: <bug-48097-78@https.issues.apache.org/bugzilla/>
References: <bug-48097-78@https.issues.apache.org/bugzilla/>
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
Message-Id: <20091102012059.9C4B8234C1F2@brutus.apache.org>
Date: Sun,  1 Nov 2009 17:20:59 -0800 (PST)

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