Ben,

Thanks for your feedback.  I'll try to respond to your issues below.  Also,
if at all possible, try using the Tomcat 3.2.2b2 release to see if it
addresses any of your concerns.

1.  Classes loaded by the container take precedence over classes from Jar
files in WEB-INF/lib.  In tomcat 3.x there really isn't anything we can do
about this.  The Servlet 2.3 (Proposed Final Draft) specification allows
containers to let classes inside the web application override those from the
container (section 9.6.2).  Tomcat 4.0 implements this specification and
does support this feature.

2.  The system wide web.xml is no longer supported in Tomcat 3.2.x because
it was a non-standard extension to the Servlet specification.  All web
application configuration is now do in WEB-INF/web.xml files within the
webapps.

3.  Agreed.  I think there are already some Bugzilla bug reports on this
topic.

4.  I think this is related to the same issue as item 1.

5.  The treatment of relative URLs is addresssed in section 2.5.2 of the JSP
1.1 specification and Tomcat 3.2.x does implement this correctly.  A URL
like "fubar.jsp" is a 'page relative' URL and will be resolved relative the
current JSP page.  A URL like "/fubar.jsp" is a 'context relative' URL and
will be interpreted rooted at the base of the web application.  There is no
mechanism to include resourses outside the web application.  A relative URL
that tries to use several ../../.. to 'escape' from the web application will
fail.

6.  The documentation can certainly be made better.  Voluteers are always
welcome!

7.  Same as above!


-----Original Message-----
From: Ben Hutchison [mailto:[EMAIL PROTECTED]]
Sent: Friday, March 30, 2001 9:00 AM
To: [EMAIL PROTECTED]
Subject: Tomcat Feedback


Hi Tomcat Developers,

I work at Finetix London, a technical consultancy working with a lot of J2EE
and XML/XSL technology. Over the last weeks, my colleage and I have been
using Tomcat 3.2.1 for JSP/Servlet development, and we encountered a couple
of glitches/issues which I describe below.


1. When using Xalan 2 with Tomcat, the default classpath shadows some Xalan
2 classes with classes in jaxp.jar and parser.jar, so that Xalan fails to
work. Editing of tomcat.bat is required to fix the problem by moving
Xalan.jar forward.


2. Inheritance of MIME mappings from the base web.xml to web apps did not
seem to work, although the docs specified this behavior. Eg: We set up a
mapping for .WML files in the base web.xml, restarted, but WML files were
served as plain text. The same mapping in the web apps /WEB_INF/web.xml file
did effect the mapping.


3. Exception messages of type org.apache.jasper.compiler.ParseException (eg:
"C:\software\tomcat\webapps\test\MyTest.jsp(20,4) Invalid directive") are
often quite uninformative. They dont supply details about the expression
that caused the problem, nor why that expression was "bad" or "invalid".
This makes development more difficult. Also these exceptions dont seem to be
logged.


4. . When using Xalan 2.0.1 with Tomcat 3.2.1, the default config shadows
some Xalan 2 classes with classes in jaxp.jar and parser.jar, so that Xalan
fails to work. Editing of tomcat.bat is required to fix the problem by
moving Xalan.jar forward. Since Xalan and Tomcat are both from Apache
projects, both recent production versions, and are very likely to be used
together, I think they should co-exist well out-of-the-box.


5. The resolution of filename URLs within JSP Pages seemed a frequent source
of trouble, (Eg <%@ include file="relative url">).
    a) We found it very difficult to determine exactly what URL format
tomcat undertstands. It didnt seem to be standard and it didnt seem to be
documented.
    b) It frequently throws exceptions for relative URLs of the form "../X"
or "./" where it reports a bad file argument, but doesnt print either the
file argument that thinks is bad, nor the reason why.
    c) We were unable to find a url form that allowed us to specify paths to
other drive letters under Windows.


6. There seems to be little or no description in the docs of how to put
pages into the server root dir. The docs focus on web-app context-linked
sub-directories. Could this be described more prominently?


7. (Minor) The /test index.html would be more useful with hyperlinks the
actual test pages below it.

Regards
Ben

Reply via email to