This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
The monitor filter and valves are designed in such a way that they propagate any exceptions thrown while a request is processed and rethrow it after they have finished processing. This is to ensure that the developer sees all error messages from the server in the same way as if the monitor was not installed. However, it turns out that I forgot to do this for the one case where the MonitorValve tries to get hold of the servlet, and the developer has forgotten to put the class in the classpath. This needs to be propagated also. To reproduce: 1. Create a web module. 2. Add a servlet using the wizard. 3. Modify the servlet so that it does something. 4. Delete the servlet, but not the dd entry. 5. Deploy the web module and access the servlet. Nothing happens. Jason, please add this scenario to the tests. Ana
Modify the valve so that the exception is thrown.
Eh... I filed this against myself too soon. It turns out that the DispatchListener has nothing to do with this, and the Valve propagates execeptions as is. Instead, the problem is with the IdeJSPServlet - I see the same behaviour if I disasble the monitor while toggling the integration mode to full or minimum. The reason I filed this bug was a report on nbusers - a user complained that the resource not found message is less helpful than seeing the actual exception. I would recommend that we at least print the exception to the log file even if we continue printing the same message in the browser. I assume that this problem will go away entirely after we change how the IDE compiles JSP, so feel free to say that this will be fixed as part of the new compilation architecture.
If I understand correclty the idea is to log exception from IdeJspServlet beside of sending the stack trace to browser. Is that right?
Right now it looks like the stack trace is not sent to the browser. You just get the Apache error page w/o the stack trace. I think the user's problem was that the exception wasn't available from anywhere (neither the log, nor the browser).
This one issue is evaluated IMO.
I believe it may be neither the valve's fault, nor the IDEJspServlet's fault. It can hardly be IDEJspServlet swallowing the exception, because it is not called at all for servlets - only for JSPs. As Ana confirmed, this does not look like the monitor's fault either. This may be related to the following Tomcat behavior: when the page is requested for the first time, Tomcat reports the whole stack trace of the exception. On subsequent requests, it only outputs the header without the exception stack trace. In fact, I see this behavior consistently in both full and mininal integration mode. Also, in both cases the exception is written into the server log, which may serve as a lead as to why the servlet was not loaded.
I am the submitter so I guess I'm OK with closing this one. I submitted it in response to a request on nbusers. The person who reported it hasn't updated the bug and probably isn't receiving notification. Perhaps the really polite thing would be to follow up on the original request... I'll see if I can find it.
We may want to close this as invalid, but first let's file a Tomcat bug. When that's done, we can close this. Setting target milestone to 4.0.
Still reproducible in NetBeans 3.6.
I think the behavior is better now - I can see the exception in the browser. Maybe an improvement in Tomcat 5.0.27 ?
Per previous comment, I think this is fixed.
VERIFIED