Change D2DViewHandler to throw FileNotFoundException when the template corresponding to the requested URL cannot be found. The View code now captures the FileNotFoundException and respond with a HTTP 404 message.
Also, the ResourceServer was modified to detect any request for resource that does not match a registered resource in order to respond with a HTTP 404 message.

Introduced TemplateNotFound runtime exception that can bubble through without having JSF logging its stack trace. This avoids verbose messages being logged during requests for inexistent pages. The solution also avoids the statefull issue introduced by the previous fix where the server will alternate 200 and 404 responses for consecutive requests.

When keep hitting the bogus URL a couple of times it could still happen that a 200 OK is being received instead of the desired 404 Not Found. Reloading the bogus URL every second or so for about 10 times shows the 200 OK for me on occasion. Reopening this issue.

When serving non-JSF pages during page load the default view handler is switched to a dispatching view handler. Also a reload command is sent back to the bridge. When the next request (for the same page) arrives the dispatch is made (for sending PDFs for example).
So the 404 response is sent while using the default view handler, the 200 response is sent by the dispatching view handler set right after the previous response was committed.

The fix applied restores the default view handler when an exception is caught while trying to serve an non JSF page.

The CachingControlledServer applies the caching procedures even when the wrapped server replies with a non-200 HTTP status code.

The fix stops the caching of the responses that do not return 200 HTTP status code.