You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by BugRat Mail System <to...@cortexity.com> on 2000/09/27 17:56:59 UTC
BugRat Report #170 has been filed.
Bug report #170 has just been filed.
You can view the report at the following URL:
<http://znutar.cortexity.com:8888/BugRatViewer/ShowReport/170>
REPORT #170 Details.
Project: Tomcat
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: high
Severity: serious
Confidence: public
Environment:
Release: Tomcat 3.1
JVM Release: 1.2.2
Operating System: Solaris
OS Release: 2.6
Platform: Unix
Synopsis:
Tomcat 3.1 uses classes from inappropriate classpath
Description:
We recently upgraded our version of Tomcat 3.1. We had
actually been running 3.1 for awhile, but discovered that
changes had been made to the release being offered by
apache.org, even though the version number hadn't been
changed. Indeed, some of the changes proved very
deleterious. Under the previous release of Tomcat 3.1,
I had been able to run parallel versions of a servlet off
the same running copy of the servlet engine: a
production version and a development version.
The two servlet versions use classes with identical names
but residing of course in different locations.
(The production version is accessed via
http://sunsite.berkeley.edu/xdlib/servlet/...
and the development version via
http://sunsite.berkeley.edu/xdlibdev/servlet/...)
The previous release of Tomcat 3.1 had no problem keeping
these two versions of my servlet sorted out; it activated
the proper classes from the proper classpath for the
version of the servlet which the URL indicated.
But under the new version of Tomcat 3.1, this has changed.
If a user invokes the xdlibdev servlet (my development
servlet), Tomcat will now use classes from the
xdlib/servlet classpath (the production servlet classpath)
if these are already loaded! In other words, it now seems
only to pay attention to the package and class names, not
to the classpath that is associated with a servlet when
loading classes for use. Surely this can't be considered a
feature!