Bug 37326 - No error reported when <jsp:include> has non-existent target
No error reported when <jsp:include> has non-existent target
Status: RESOLVED FIXED
Product: Tomcat 5
Classification: Unclassified
Component: Servlet & JSP API
5.5.12
PC Windows XP
: P2 normal with 1 vote (vote)
: ---
Assigned To: Tomcat Developers Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2005-11-01 22:59 UTC by Steve Kirk
Modified: 2008-02-18 13:06 UTC (History)
0 users



Attachments
example war file (2.01 KB, application/octet-stream)
2005-11-01 23:00 UTC, Steve Kirk
Details
tomcat.log using log4j with DEBUG level for ApplicationDispatcher (2.91 KB, text/plain)
2005-11-29 11:33 UTC, Steve Kirk
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Steve Kirk 2005-11-01 22:59:43 UTC
I'm not sure this is a bug - might be expected behaviour - I'm not expert in 
this area.  Have tried to ascertain what should be happening, by reading the 
servlet/JSP spec docs and parts of the TC source code, but I'm still not quite 
sure.  I posted to tomcat-user twice seeking help on this (no responses).

The problem that I'm seeing is that when a JSP page includes one or more JSP 
fragments using <jsp:include> actions, but the fragment files don't exist, the 
including JSP page is returned to the browser without the fragments included.  
It's as if the including JSP ignores the missing fragments and continues being 
processed.  The including page is returned with SC of 200, as if there is no 
problem. Nothing is written to any log file to indicate the problem.

I would have expected this to return an exception or a 404, but neither 
happens.  Is this the expected behaviour?  As it stands, a webapp bug like 
this could go unnoticed for quite some time.  Normally TC is good at bringing 
bugs like this to the developer's attention.

See attached war for simple example.  First discovered on 5.5.9, verified same 
behaviour on 5.5.12, both based on fresh TC installs.

I appreciate that once the including JSP has written the part of its response 
before the include, the response could already be committed depending on 
buffer size, so calling sendError() will cause an IllegalStateException.  
Also, may not be possible to return an error page at this point, again because 
the response is already committed...?  Perhaps though an exception could be 
logged?  Or, perhaps (?)the including page's processing should be stopped, 
rather than allowing it to continue.

Some other info: I only discovered that I had omitted the fragment files from 
my warfile when I first started TC from NetBeans rather than from TC batch 
scripts.  When I did this, the missing fragments are then reported with SC 
404.  As far as I can tell, it seems that the addition of the NetBeans 
HTTPMonitorFilter to conf/web.xml is what causes the 404 to be reported where 
it was previously silent.  Have drawn a blank on why this might be.

For more info (my posts to tc-user) see also: http://marc.theaimsgroup.com/?
l=tomcat-user&m=113034098008166&w=2
Comment 1 Steve Kirk 2005-11-01 23:00:53 UTC
Created attachment 16849 [details]
example war file
Comment 2 Yoav Shapira 2005-11-28 21:27:21 UTC
I'm looking at org.apache.catalina.core.ApplicationDispatcher (which I think is
the relevant class), and it seems to log and re-throw all the exceptions. 
Steve, can you please retry it on 5.5.12 with DEBUG-level logging enabled for
this class, and post your findings when you get a chance?  Thanks.
Comment 3 Steve Kirk 2005-11-29 11:32:42 UTC
(In reply to comment #2)
OK have done that.  Used fresh install of TC5.5.12 installed as windows 
service using the service.bat script (which is my standard dev setup).  TC is 
unmodified from standard install, except that I added my test.war (attached) 
to the webapps folder. No other changes to standard setup.  PS am using jdk 
1.5.0_02-b09

For some reason could not get DEBUG/ALL logging of the class to work with 
java.util.logging (which is what I normally use), so installed log4j instead 
exactly as described on the logging docs page (at 
http://tomcat.apache.org/tomcat-5.5-doc/logging.html), with the exception that 
I modified log4j.properties as shown below to give DEBUG level on the 
ApplicationDispatcher, hope this is correct, not sure as do not know log4j 
well:

log4j.rootLogger=info, R 
log4j.appender.R=org.apache.log4j.RollingFileAppender 
log4j.appender.R.File=${catalina.home}/logs/tomcat.log 
log4j.appender.R.MaxFileSize=10MB 
log4j.appender.R.MaxBackupIndex=10 
log4j.appender.R.layout=org.apache.log4j.PatternLayout 
log4j.appender.R.layout.ConversionPattern=%p %t %c - %m%n 
log4j.logger.org.apache.catalina.core.ApplicationDispatcher=DEBUG

Then ran the request to http://localhost:8080/test/ to test the attached war.  
Page worked fine as before, no reported errors in logfile or browser, despite 
one of the included files being missing from the webapp.  The entire contents 
of the resulting tomcat.log are attached.

Hope this helps, just let me know if you need anything else.
Comment 4 Steve Kirk 2005-11-29 11:33:40 UTC
Created attachment 17073 [details]
tomcat.log using log4j with DEBUG level for ApplicationDispatcher
Comment 5 Yoav Shapira 2005-11-29 15:11:43 UTC
Steve, thank you.  This helps.  I'll try to find more time to look at this
within the next few days.
Comment 6 Yoav Shapira 2006-12-26 16:45:30 UTC
Ooops, I guess I didn't get to this in a few days, did I?  It's piqued my
curiosity again.  Thanks for going through the debugging steps and attaching the
WAR.  Your log4j configuration looks fine.  I'll try to run an instrumented
version of the code locally with more logging statements and see if I can learn
anything.
Comment 7 Mark Thomas 2007-08-04 11:20:08 UTC
This has been fixed in 5.5.x and 6.0.x and will be included in the next releases
of each.
Comment 8 Adam Rabung 2008-02-18 12:36:32 UTC
Is it possible to disable this behavior with configuration?  I love the addition
of this error, but I don't want to have to update legacy versions of my app.
Comment 9 Mark Thomas 2008-02-18 13:06:28 UTC
I am afraid not.