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