You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Ben Hutchison <Be...@finetix.com> on 2001/03/30 17:00:05 UTC
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
Re: Tomcat Feedback
Posted by Chandra Goliva <ch...@gene.COM>.
Hi Tomcat developer/user community,
I am using Tomcat 3.2.1.
Did you notice any problem while forwarding from a Servlet/JSP to a target
JSP,which is a quite large in size? which may be something related to jsp
comilation could not be finished in a certain time/ is too big in size to occupy
run timememory.
Its a kind of strange but I had this problem in Tomcat where as it works fine
with other web server like WebLogic.
But surprisingly this worked once a part of the Target JSP is removed ie.,
cutting down the size of target JSP.
can you throw some light onto this? any sugestions/solutions/fixes or
work-arounds are appreciated.Update me if u had similar kind of problem.
thanks in advance,
Chandra
Marc Saegesser wrote:
> 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:Ben.Hutchison@finetix.com]
> Sent: Friday, March 30, 2001 9:00 AM
> To: tomcat-dev@jakarta.apache.org
> 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
RE: Tomcat Feedback
Posted by cm...@yahoo.com.
On Fri, 30 Mar 2001, Marc Saegesser wrote:
> 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.
Marc, a small correction here: tomcat 3.3 doesn't have this problem - the
container is loaded in a completely separated class loader ( that includes
jaxp, parser, modules, etc) - the webapplications and the container are
sharing only javax.servlet.* package and the core ( i.e. 6 classes + 10
utils - not even that is required and you can reconfigure that )
That means you shouln't have any problem with "sealing" or plugging a
different parser.
The downside is that webapps no longer have a parser provided by default -
but that's easy to fix by including one in lib/apss ( not necesarily the
same used by the container ).
With the (experimental) ProfileLoader you can have different jaxp parsers
or jars available to groups of applications.
Tomcat 3.3 doens't support the "overriding" feature - but it doesn't have
anything exposed that would need to be overriden - the apps get a clean
environment, unless configured in a different way - in which case the
configured jars do override the app jars. ( this is important for things
like JDBC drivers and sandboxing, since you'll grand permissions to the
container's jar - instead of granting them to the jar in the webapp that
can be corupted.
Nacho can explain more about this, as he did most of the work.
Costin
( of course, the 3.3 loading also support the "multiple facades" feature -
but it needs some special configurations to run servlet23/servet22 at the
same time )
RE: Tomcat Feedback
Posted by Marc Saegesser <ma...@apropos.com>.
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:Ben.Hutchison@finetix.com]
Sent: Friday, March 30, 2001 9:00 AM
To: tomcat-dev@jakarta.apache.org
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