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
Created attachment 16849 [details] example war file
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.
(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.
Created attachment 17073 [details] tomcat.log using log4j with DEBUG level for ApplicationDispatcher
Steve, thank you. This helps. I'll try to find more time to look at this within the next few days.
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.
This has been fixed in 5.5.x and 6.0.x and will be included in the next releases of each.
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.
I am afraid not.