mraible wrote:
In my web application, I prefer to have FacesServlet mapped to *.html. This has worked fine for me for the last couple of years. Recently, I've tried to add a StaticFilter that looks for static files (i.e. /content/faq.html) and dispatches to those if they're found. If they're not found, I dispatch to the FacesServlet, which doesn't have a <servlet-mapping> in web.xml. This all works great, except that <h:commandLink> seems to need the servlet mapping in order to create its links. If I have the following in my web.xml:<!-- No servlet-mapping - StaticFilter handles forwarding to "faces" servlet when no static files found --> <!--servlet-mapping> <servlet-name>faces</servlet-name> <url-pattern>*.html</url-pattern> </servlet-mapping--> <servlet-mapping> <servlet-name>dwr-invoker</servlet-name> <url-pattern>/dwr/*</url-pattern> </servlet-mapping> Links are rendered as /dwr/foo.xhtml instead of /foo.html. Is this a known issue? Is there a better way to do what I'm trying to do (without using a different extension)?
I'm surprised you had so few problems. I struck a similar issue just this week, as I wrote a variant of Sitemesh applyDecorator that handles JSF "decorator" content when the main page is not JSF (and therefore the servlet that was activated did not have a JSF mapping).
The form renderer, however, uses the mapping of the "current" Servlet in order to determine what url to render in the form "action" attribute. In my case (and yours too) the servlet is not actually the FacesServlet so the action attribute is wrong and therefore anything that submits a form breaks (not just commandLink but commandButton too).
The form renderer uses JspViewHandlerImpl.getActionURL to determine what url to output as the "action" attribute of the form tag. If this is wrong then of submit of the form bad things obviously happen. But the getActionURL method really assumes that the servlet which was invoked by this request is the FacesServlet which is not always the case here. In particular, it uses ExternalContext.getRequestPathInfo to determine whether the servlet is mapped using extensions or "paths".
My workaround was to create a subclass of HttpServletRequestWrapper that fudges the getPathInfo etc. to trick JSF into thinking the JSF servlet was invoked.
Regards, Simon
