javaserverfaces
  1. javaserverfaces
  2. JAVASERVERFACES-890

ViewHandlerImpl always adding .jsf mapping to navigated viewId's

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.2_10
    • Fix Version/s: 1.2_11-b01
    • Component/s: None
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      890

      Description

      I'm using JSF RI 1.2.10 + Facelets 1.1.15b + RichFaces 3.2.2 on Glassfish v2 all
      running on JDK

      The first of my web.xml faces mapping is:
      <servlet-mapping>
      <servlet-name>Faces Servlet</servlet-name>
      <url-pattern>*.jsf</url-pattern>
      </servlet-mapping>
      There are others with paths.

      I am currently trying to implement short/pretty Urls. I have reported a couple
      of things on the scales issue tracking. Not only am I using a (tweaked) version
      of the PrettyUrlPhaseListener one can find there, but I also developped my own
      outputLink-like component for rendering pretty Urls. So that, basically, all the
      (output) URLs rendered in my page are like (for example)
      http://<host>/<context>/login/ instead of
      http://<host>/<context>/secure/userLogin.jsf

      Behind the scenes, there is a ServletRequest wrapper that "switches" to the
      right view. Its pathInfo is null and servletPath equals the 'real' viewId to
      render (/secure/userLogin.jsf if we stick to my example).

      All this works fine, but I needed to adapt my navigation cases as well, so that
      the user never sees any .jsf page in his address bar.

      I changed my navigation cases to blocks like:
      <navigation-case>
      <from-outcome>userLogin</from-outcome>
      <!-- <to-view-id>/secure/userLogin.jsf</to-view-id> -->
      <to-view-id>/admin/login/</to-view-id>
      <redirect/>
      </navigation-case>
      (You can see the previous code commented.)

      I didn't change the commandLink/commandButtons I had in my .xhtml pages:
      <h:commandLink action="customerLogin" value="Sign in"/>

      However, when I click on such a commandLink or commandButton, I get redirected
      to /admin/login/.jsf instead of just /admin/login/, which, obviously ends up on
      a 404.

      I had a look at com.sun.faces.applicationViewHandlerImpl#getActionURL and line
      682, the mapping (extension in fact) is added everytime, no matter what the
      viewId is. At that time, viewId is /admin/login/, as it's before the redirect
      caused by the navigation case. After that however, the redirect is supposed to
      be "intercepted" by the PrettyUrlPhaseListener and the "new" viewId to be the
      mapping, that is /secure/userLogin.jsf in our case.

      Just for the sake of checking, I had a look at MyFaces, v1.2.5,
      org.apache.myfaces.application.DefaultViewHandlerSupport#calculateActionURL. The
      code looks more lenient there, I am not 100% sure but I think my hellskitchen
      would work.

      So, is it OK to call something that's not a jsf page in a navigation case? As
      far as I'm concerned, I believe so, it enables short url tweaks.

        Activity

        Hide
        Ryan Lubke added a comment -

        assigned

        Show
        Ryan Lubke added a comment - assigned
        Hide
        Ryan Lubke added a comment -

        Created an attachment (id=717)
        Proposed Changes (ver. 1)

        Show
        Ryan Lubke added a comment - Created an attachment (id=717) Proposed Changes (ver. 1)
        Hide
        driscoll added a comment -

        r=driscoll

        Show
        driscoll added a comment - r=driscoll
        Hide
        Ryan Lubke added a comment -

        Changes applied to 1.2. Please try tonight's nightly build to confirm
        resolution of your issue. Reopen the issue if necessary.

        Thanks.

        Show
        Ryan Lubke added a comment - Changes applied to 1.2. Please try tonight's nightly build to confirm resolution of your issue. Reopen the issue if necessary. Thanks.
        Hide
        fabmars added a comment -

        Works fine for me.
        No regression seen in the rest of the code.

        Thanks to you.

        Show
        fabmars added a comment - Works fine for me. No regression seen in the rest of the code. Thanks to you.
        Hide
        Manfred Riem added a comment -

        Closing issue out

        Show
        Manfred Riem added a comment - Closing issue out

          People

          • Assignee:
            Ryan Lubke
            Reporter:
            fabmars
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: