ICEfaces
  1. ICEfaces
  2. ICE-6063

<ice:graphicImage> Incorrect Path Processing for JSF2.0 Resources

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0-Beta1
    • Fix Version/s: 2.0-Beta2, 2.0.0
    • Component/s: ICE-Components
    • Labels:
      None
    • Environment:
      Glassfish 3.0.1
    • Workaround Exists:
      Yes
    • Workaround Description:
      Use a plain HTML <img> or <h:graphicImage>.

      Description

      When using a <ice:graphicImage> to render an image resource by passing corresponding EL as the value attribute, the root folder of the path (in this case the project name) is duplicated. This was noticed during testing of the easyPopup component.

      <ice:graphicImage value="#{resource['images/tabs:popupclose.gif']}">
      produces an image tag with the src attribute:
      "/YACS/YACS/javax.faces.resource/popupclose.gif.jsf?ln=images/tabs"

      while the EL alone renders as:
      "/YACS/javax.faces.resource/popupclose.gif.jsf?ln=images/tabs"


      ice:graphicImage as expected, cannot find the resource.
      h:graphicImage is unaffected.

        Activity

        Nils Lundquist created issue -
        Hide
        Nils Lundquist added a comment -

        A bug with the processing of paths given to ice:graphicImage.

        Show
        Nils Lundquist added a comment - A bug with the processing of paths given to ice:graphicImage.
        Nils Lundquist made changes -
        Field Original Value New Value
        Assignee Ken Fyten [ ken.fyten ]
        Hide
        Nils Lundquist added a comment -

        This issue effects the image attribute of the <ice:commandButton> component.

        Show
        Nils Lundquist added a comment - This issue effects the image attribute of the <ice:commandButton> component.
        Hide
        Patrick Corless added a comment -

        Can you test if the use of the target and name attributes show the same problem as when you use the EL short hand? For example:

        <ice:graphicImage target="images/tabs" name="popupclose.gif" />

        Show
        Patrick Corless added a comment - Can you test if the use of the target and name attributes show the same problem as when you use the EL short hand? For example: <ice:graphicImage target="images/tabs" name="popupclose.gif" />
        Hide
        Ken Fyten added a comment -

        From Deryk:

        I did a search of places in the components where we use the ViewHandler.getResourceURL and there's a number of them. We have a CoreUtils class that has a resolveResourceURL method and it just calls:

        return facesContext.getApplication().getViewHandler().getResourceURL(facesContext, path);

        So we could:

        • change all the direct calls to ViewHandler.getResourceURL to CoreUtils.resolveResourceURL which I assume was the original intention
        • add the context stripping logic into the CoreUtils.resolveResourceURL so that it behaves like the old JSF 1.2 logic
        Show
        Ken Fyten added a comment - From Deryk: I did a search of places in the components where we use the ViewHandler.getResourceURL and there's a number of them. We have a CoreUtils class that has a resolveResourceURL method and it just calls: return facesContext.getApplication().getViewHandler().getResourceURL(facesContext, path); So we could: change all the direct calls to ViewHandler.getResourceURL to CoreUtils.resolveResourceURL which I assume was the original intention add the context stripping logic into the CoreUtils.resolveResourceURL so that it behaves like the old JSF 1.2 logic
        Ken Fyten made changes -
        Salesforce Case []
        Fix Version/s 2.0-Beta2 [ 10242 ]
        Assignee Priority P2
        Affects Version/s 2.0-Beta1 [ 10231 ]
        Assignee Ken Fyten [ ken.fyten ] Deryk Sinotte [ deryk.sinotte ]
        Repository Revision Date User Message
        ICEsoft Public SVN Repository #22509 Tue Oct 05 08:25:32 MDT 2010 deryk.sinotte ICE-6063: adjust logic to remove requestContextPath before processing with ViewHandler and update components to use the CoreUtils API
        Files Changed
        Commit graph MODIFY /icefaces2/trunk/icefaces/core/src/main/java/org/icefaces/impl/application/PropagatingNavigationHandler.java
        Commit graph MODIFY /icefaces2/trunk/icefaces/compat/core/src/main/java/com/icesoft/faces/renderkit/dom_html_basic/DomBasicRenderer.java
        Commit graph MODIFY /icefaces2/trunk/icefaces/compat/components/src/main/java/com/icesoft/faces/component/inputrichtext/InputRichTextRenderer.java
        Commit graph MODIFY /icefaces2/trunk/icefaces/compat/components/src/main/java/com/icesoft/faces/component/dataexporter/DataExporterRenderer.java
        Commit graph MODIFY /icefaces2/trunk/icefaces/compat/core/src/main/java/com/icesoft/faces/util/CoreUtils.java
        Commit graph MODIFY /icefaces2/trunk/icefaces/compat/components/src/main/java/com/icesoft/faces/component/outputresource/OutputResourceRenderer.java
        Commit graph MODIFY /icefaces2/trunk/icefaces/compat/core/src/main/java/com/icesoft/faces/application/ExtrasSetup.java
        Commit graph MODIFY /icefaces2/trunk/icefaces/compat/core/src/main/java/com/icesoft/faces/renderkit/dom_html_basic/ImageRenderer.java
        Commit graph MODIFY /icefaces2/trunk/icefaces/compat/core/src/main/java/com/icesoft/faces/context/ResourceRegistryLocator.java
        Hide
        Deryk Sinotte added a comment -

        The issue appeared to be that the ViewHandler.getResourceURL method in JSF 1.2 would check for the /context and remove it if it was there. Subsequent processing would add it back in if necessary. The ViewHandler impl in JSF 2.0 doesn't do this. So I added the /context removal logic back into our compat CoreUtils.resolveResourceURL call and then updated all the other components that weren't using this method (ie using facesContext.getApplication().getViewHandler().getResourceURL directly) to use the CoreUtils API.

        Show
        Deryk Sinotte added a comment - The issue appeared to be that the ViewHandler.getResourceURL method in JSF 1.2 would check for the /context and remove it if it was there. Subsequent processing would add it back in if necessary. The ViewHandler impl in JSF 2.0 doesn't do this. So I added the /context removal logic back into our compat CoreUtils.resolveResourceURL call and then updated all the other components that weren't using this method (ie using facesContext.getApplication().getViewHandler().getResourceURL directly) to use the CoreUtils API.
        Deryk Sinotte made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Ken Fyten made changes -
        Fix Version/s 2.0.0 [ 10230 ]
        Ken Fyten made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Assignee Priority P2

          People

          • Assignee:
            Deryk Sinotte
            Reporter:
            Nils Lundquist
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: