0

I'm trying as simply as possible to deal with error handling in a "forked" JSF2 application, which has separate templates and XHTML page paths for mobile and desktop.

The main servlet mapping (maybe in need of modification) currently looks like this

<servlet-mapping>
    <servlet-name>Faces Servlet</servlet-name>
    <url-pattern>/faces/*</url-pattern>
    <url-pattern>/javax.faces.resource/*</url-pattern>
</servlet-mapping>

In my situation, this works fine for handling desktop errors:

<error-page>
    <error-code>404</error-code>
    <location>/faces/webpages/filenotfound.xhtml</location>
</error-page>
<error-page>
    <exception-type>java.io.FileNotFoundException</exception-type>
    <location>/faces/webpages/filenotfound.xhtml</location>
</error-page>

But given the forked sets of pages and templates, I would also like to have

<error-page>
    <error-code>404</error-code>
    <location>/faces/mpages/filenotfound.xhtml</location>
</error-page>
<error-page>
    <exception-type>java.io.FileNotFoundException</exception-type>
    <location>/faces/mpages/filenotfound.xhtml</location>
</error-page>

Is there a way to do this directly in the web.xml, either using paths that aren't relative to the context root or by nesting some of the config in blocks that define the path to use in different scenarios? Or to use faces-config.xml and create custom outcomes that can be matched to exact XHTML file locations?

Kukeltje
  • 12,223
  • 4
  • 24
  • 47
Jasman
  • 143
  • 1
  • 10

1 Answers1

0

Well, I didn't get a response (and didn't really think I would). For what it's worth, here's what I did to get the desired result.

  1. Created a new 404.jsp page
  2. Renamed my xhtml pages to 404.xhtml for clarity and brevity
  3. In the body, inserted code similar to this:

String pageRoot = MobileChecker.isMobile( request ) ? "mpages" : "webpages"; if(!response.isCommitted()) { response.sendRedirect(request.getContextPath() + "/faces/" + pageRoot + "/404.xhtml"); }

The "MobileChecker" part is an unfortunate, old part of our codebase, but do whatever works to detect that the device in question should be treated as "mobile" (UA sniffing can be part of it, but feature detection passed from the client may be better). We already also have this setup at the server level, so that requests to the app root are already redirected to the /webpages or /mpages paths, accordingly.

So far, this approach generally seems to work.

Jasman
  • 143
  • 1
  • 10