Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0
    • Fix Version/s: 2.2 Sprint 11 B
    • Component/s: Navigation
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: Macintosh

    • Issuezilla Id:
      809
    • Status Whiteboard:
      Hide

      size_large importance_medium

      Show
      size_large importance_medium
    • Tags:

      Description

      In Facelets 1.x, it was possible to implement load views from external locations (such as the class path,
      or a repository) by providing a ResourceResolver implementation.

      The ResourceResolver is also present in JSF 2, so this is still possible. However, there is a new
      requirement. Implicit navigation calls ExternalContext.getResource() to determine whether a view id
      corresponds to a physical resource. If ExternalContext.getResource() returns a non-null URL, implicit
      navigation to the view id is allowed.

      This contract is not ideal, as:

      1. It is non-obvious.
      2. It requires hooking into multiple locations.
      3. It makes it difficult to distinguish between requests for view ids vs. other types of resources.

      Regarding #3… ExternalContext.getResource() may be used for all sorts of resources. In our case we
      only want to search our external repositories when a view id is requested, but not, say, when someone
      calls getResource() to load some other type of file (eg. a style sheet).

      We need to introduce a cleaner contract that simplifies the responsibilities for custom view loading
      implementations.

        Issue Links

          Activity

          Hide
          arjan tijms added a comment -

          Regarding #3… ExternalContext.getResource() may be used for all sorts of resources. In our case we
          only want to search our external repositories when a view id is requested, but not, say, when someone
          calls getResource() to load some other type of file (eg. a style sheet).

          I know the issue is resolved and closed, but I'm just wondering about the original intend.

          The description makes it sound like ExternalContext.getResource() has to be overridden in addition to providing a ResourceResolver to fully support loading views from another location. Supposedly implicit navigation directly called ExternalContext.getResource().

          But, this is not what happens at all in JSF 2.1.

          Implicit navigation and all other cases that need to interact with the physical location of the view already go through the ResourceResolver. This is clear from the stacktraces Ed posted on 24/Feb/12 09:13 PM

          So, in order to satisfy "we only want to search our external repositories when a view id is requested", the existing ResourceResolver already fully did the job and "2. It requires hooking into multiple locations." doesn't apply.

          Maybe I'm completely missing something though.

          The new mechanism does seem inline with the comment made by kito on 19/Apr/11

          Show
          arjan tijms added a comment - Regarding #3… ExternalContext.getResource() may be used for all sorts of resources. In our case we only want to search our external repositories when a view id is requested, but not, say, when someone calls getResource() to load some other type of file (eg. a style sheet). I know the issue is resolved and closed, but I'm just wondering about the original intend. The description makes it sound like ExternalContext.getResource() has to be overridden in addition to providing a ResourceResolver to fully support loading views from another location. Supposedly implicit navigation directly called ExternalContext.getResource() . But, this is not what happens at all in JSF 2.1. Implicit navigation and all other cases that need to interact with the physical location of the view already go through the ResourceResolver . This is clear from the stacktraces Ed posted on 24/Feb/12 09:13 PM So, in order to satisfy "we only want to search our external repositories when a view id is requested", the existing ResourceResolver already fully did the job and "2. It requires hooking into multiple locations." doesn't apply. Maybe I'm completely missing something though. The new mechanism does seem inline with the comment made by kito on 19/Apr/11
          Hide
          aschwart added a comment -

          Hi Arjan -

          The description makes it sound like ExternalContext.getResource() has to be overridden in addition to providing a ResourceResolver to fully support loading views from another location. Supposedly implicit navigation directly called ExternalContext.getResource().

          But, this is not what happens at all in JSF 2.1.

          Right.

          The issue was originally filed back in 2010, before 2.1 existed.

          In 2.0.x, Mojarra's MultiViewHandler.convertViewId() contains the following logic:

          if (context.getExternalContext().getResource(convertedViewId) != null)

          Unknown macro: { // RELEASE_PENDING (rlubke,driscoll) cache the lookup return convertedViewId; }

          This code is checking for the presence of a view corresponding to a viewId by calling ExternalContext.getResource(). This of course fails for views that are known to the ResourceResolver, but are not accessible via ExternalContext.getResource(). As such, frameworks that plug into the ResourceResolver to enhance the set of views that are available must also plug into ExternalContext.getResource().

          We addressed this in 2.1.x with the addition of ViewDeclarationLanguage.viewExists().

          As of 2.1.x, the above MultiViewHandler code has been replaced with:

          if (vdl.viewExists(context, convertedViewId))

          Unknown macro: { // RELEASE_PENDING (rlubke,driscoll) cache the lookup return convertedViewId; }

          And FaceletViewHandlingStrategy implements this as:

          return faceletFactory.getResourceResolver().resolveUrl(viewId) != null;

          This removes the need for frameworks that provide a ResourceResolver to also plug into ExternalContext.getResource().

          Show
          aschwart added a comment - Hi Arjan - The description makes it sound like ExternalContext.getResource() has to be overridden in addition to providing a ResourceResolver to fully support loading views from another location. Supposedly implicit navigation directly called ExternalContext.getResource(). But, this is not what happens at all in JSF 2.1. Right. The issue was originally filed back in 2010, before 2.1 existed. In 2.0.x, Mojarra's MultiViewHandler.convertViewId() contains the following logic: if (context.getExternalContext().getResource(convertedViewId) != null) Unknown macro: { // RELEASE_PENDING (rlubke,driscoll) cache the lookup return convertedViewId; } This code is checking for the presence of a view corresponding to a viewId by calling ExternalContext.getResource(). This of course fails for views that are known to the ResourceResolver, but are not accessible via ExternalContext.getResource(). As such, frameworks that plug into the ResourceResolver to enhance the set of views that are available must also plug into ExternalContext.getResource(). We addressed this in 2.1.x with the addition of ViewDeclarationLanguage.viewExists(). As of 2.1.x, the above MultiViewHandler code has been replaced with: if (vdl.viewExists(context, convertedViewId)) Unknown macro: { // RELEASE_PENDING (rlubke,driscoll) cache the lookup return convertedViewId; } And FaceletViewHandlingStrategy implements this as: return faceletFactory.getResourceResolver().resolveUrl(viewId) != null; This removes the need for frameworks that provide a ResourceResolver to also plug into ExternalContext.getResource().
          Hide
          aschwart added a comment -

          BTW, Arjan - thank you for http://jdevelopment.nl/jsf-22/ !! :-D

          Show
          aschwart added a comment - BTW, Arjan - thank you for http://jdevelopment.nl/jsf-22/ !! :-D
          Hide
          arjan tijms added a comment -

          The issue was originally filed back in 2010, before 2.1 existed.
          [...]
          This removes the need for frameworks that provide a ResourceResolver to also plug into ExternalContext.getResource().

          Okay, it's clear now Basically this issue was already solved by the addition of ViewDeclarationLanguage.viewExists() in 2.1 and could have been closed then (but it's still great 2.2 went a bit beyond the initial solution). Thanks for the explanation.

          thank you for http://jdevelopment.nl/jsf-22/

          You're welcome! Incidentally, it's for that page mostly that I was wondering about the intent of this issue I also wondered about this since for the OmniFace's extensionless URL support I make heavy use of the ResourceResolver and feared I might have missed something.

          Thanks again for explaining.

          Show
          arjan tijms added a comment - The issue was originally filed back in 2010, before 2.1 existed. [...] This removes the need for frameworks that provide a ResourceResolver to also plug into ExternalContext.getResource(). Okay, it's clear now Basically this issue was already solved by the addition of ViewDeclarationLanguage.viewExists() in 2.1 and could have been closed then (but it's still great 2.2 went a bit beyond the initial solution). Thanks for the explanation. thank you for http://jdevelopment.nl/jsf-22/ You're welcome! Incidentally, it's for that page mostly that I was wondering about the intent of this issue I also wondered about this since for the OmniFace's extensionless URL support I make heavy use of the ResourceResolver and feared I might have missed something. Thanks again for explaining.
          Hide
          Manfred Riem added a comment -

          Closing resolved issue out

          Show
          Manfred Riem added a comment - Closing resolved issue out

            People

            • Assignee:
              Ed Burns
              Reporter:
              aschwart
            • Votes:
              2 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 2 hours
                2h