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

        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.
        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
        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.

          People

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

            Dates

            • Created:
              Updated:
              Resolved: