This is just a wild guess, but is it possible that you have configured the servlet mapping for faces in your web.xml to *.css?
If an error occurs, and seam is in debug mode (<core:init debug="true" …), you are usually redirected to the debug page, which is by default debug.seam. With the url pattern *.css this would be debug.css.
Other than that I would not know why this happened.
I have found some further information on this mystery.
My web.xml contains the following to enable the tomcat StreamingAddResource capabilities:
<context-parm> <param-name>org.apache.myfaces.ADD_RESOURCE_CLASS</param-name> <param-value>org.apache.myfaces.component.html.util.StreamingAddResource</param-value> </context-param>
The documentation associated with this mentions to use the
<t:document> tag in place of <html>
<t:documentHead> in place of <head>
<t:documentBody> in place of <body>
in order to enable its functionality.
The first two suggested replacements seem to be the source of the trouble. Simply reverting to the use of a normal
<html> and <head>
tags seems to have removed the mysterious redirect to a non-existent URL. Furthermore, the underlying problem appears to stem from the fact that the Tomahawk Extensions filter is producing this bad URL based upon an underlying NPE. This bug is documented under TOMAHAWK-699 at http://issues.apache.org/jira/browse/TOMAHAWK-699 which specifically refers to the documentHead tag being the source of the NPE.
I guess I'm a bit concerned that this has not been found by anyone else as I am under the impression that my technology stack is in very common use. Has noone else seen this problem? Is there a better fix than what I have found? Could there be anything else wrong that would be making my application somehow unique enough to trigger this problem when everyone else does not appear to?
Thanks for your thoughts and ideas.
Thanks for the reply Kariem.
It runs out that it was not a servlet mapping problem (see my earlier self-reply from today).
I did, however, learn something about seam debug behavior via
(<core:init debug="true" ...
With the debug value set to true, the underlying exception was completely masked from the console output as well as my web.xml defined
. Once I set this value to false, the
and console both showed me the underlying error and I was able to proceed from there. Is this a know 'feature' of the seam debug behavior? In this case (perhaps a truely exceptional one), it appears to have masked the problem, for whatit's worth.
When using seam debug mode, it's expecting you to use the Seam debug page, not the servlet error page.
Outside of the
in components.xml and the
facelets.DEVELOPMENT = true
in the web.xml, is there anything else that I need to to to enable/configure the seam debug page?
I had both of the above set up to enable debug in my original configuration. Do, if not, then it still appears that the underlying exception was being masked by the debug settings in this corner case?
is just there as a complete fallback as well as for some other non-seam pages that will ultimately end up in this app.
You need include jboss-seam-debug.jar in WEB-INF/lib.
I have had WEB-INF/lib/jboss-seam-debug.jar in the app all along, so this does not appear to be the source of the trouble.