ICEfaces
  1. ICEfaces
  2. ICE-8020

CompatResourceServlet resources cannot be downloaded by a WSRP Consumer

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 3.0.1, EE-3.0.0.GA
    • Fix Version/s: None
    • Component/s: ICE-Components
    • Labels:
      None
    • Environment:
      Liferay 6.1 WSRP, Liferay Faces Bridge
    • Workaround Exists:
      Yes
    • Workaround Description:
      Suggestion is to avoid this issue by using the ICEfaces ACE components instead of the ICEfaces Compat components.

      Description

      ICEfaces 3.0.1 is generally working in Liferay Portal 6.1 WSRP and Liferay Faces Bridge, but ICEfaces 1.8 compatibility components like ice:selectInputDate aren't rendering properly.

      The problem stems from the fact that the 1.8 compatibility components rely on context-path relative URLs, rather than the JSF2 #{resource} EL keyword.

      For example, here is how the theme CSS is typically loaded in a portlet:
      {code}
      <link href="#{request.contextPath}/xmlhttp/css/rime/rime-portlet.css" rel="stylesheet" type="text/css"/>
      {code}
      ... and the rendered <link> tag typically looks like this:
      {code}
      <link href="/my-portlet/xmlhttp/css/rime/rime-portlet.css" rel="stylesheet" type="text/css"/>
      {code}
      This is a problem because it ultimately relies on the /my-portlet context-path of the request, which is not compatible with WSRP. If the xp-rime.css were able to be retrieved with the JSF2 h:outputStyleSheet component, then the WSRP problem would be solved, because it would be retrieved with a portlet ResourceURL that WSRP knows how to rewrite for the WSRP Consumer to download. Something like this:
      {code}
      <h:outputStyleSheet library="icefaces-rime-portlet" name="rime-portlet.css" />
      {code}
      But this wouldn't solve the problem entirely -- here is a fragment of CSS from rime-portlet.css:
      {code}
      input.iceSelInpDateOpenPopup, input.iceSelInpDateOpenPopup-dis {
          background-image: url(css-images/cal_button.gif);
      }
      {code}
      The problem here is that cal_button.gif is expected to live relative to the xp-rime.css file, in a URL like "/my-portlet/xmlhttp/css/rime/css-images/cal-button.gif" but you can't make that context-path-relative assumption with WSRP. To fix this problem, the #{resource} EL keyword would have to be used within the rime.css file for each image resource, something similar to this:
      {code}
      input.iceSelInpDateOpenPopup, input.iceSelInpDateOpenPopup-dis {
          background-image: url("#{resource['icefaces-rime-portlet:images/cal-button.gif']}");
      }
      {code}
      I thought that a workaround could be to deploy a lightweight webapp in the same server as the WSRP Consumer that contains the CompatResourceServlet and theme resources. But it isn't good enough, because the relative URLs from xp-rime.css would produce WSRP errors because they can't simply be appended to a wsrp_rewrite URL.

        Activity

        Neil Griffin created issue -
        Neil Griffin made changes -
        Field Original Value New Value
        Summary Compat component theme resources cannot be downloaded by a WSRP Consumer CompatResourceServlet resources cannot be downloaded by a WSRP Consumer
        Salesforce Case []
        Neil Griffin made changes -
        Salesforce Case []
        Description ICEfaces 3.0.1 is generally working in Liferay Portal 6.1 WSRP and Liferay Faces Bridge, but ICEfaces 1.8 compatibility components like ice:selectInputDate aren't rendering properly.

        The problem stems from the fact that the 1.8 compatibility components rely on context-path relative URLs, rather than the JSF2 #{resource} EL keyword.

        For example, here is how the theme CSS is typically loaded in a portlet:
        {code}
        <link href="#{request.contextPath}/xmlhttp/css/rime/rime-portlet.css" rel="stylesheet" type="text/css"/>
        {code}
        ... and the rendered <link> tag typically looks like this:
        {code}
        <link href="/my-portlet/xmlhttp/css/rime/rime-portlet.css" rel="stylesheet" type="text/css"/>
        {code}
        This is a problem because it ultimately relies on the /my-portlet context-path of the request, which is not compatible with WSRP. If the xp-rime.css were able to be retrieved with the JSF2 h:outputStyleSheet component, then the WSRP problem would be solved, because it would be retrieved with a portlet ResourceURL that WSRP knows how to rewrite for the WSRP Consumer to download. Something like this:
        {code}
        <h:outputStyleSheet library="icefaces-rime-portlet" name="rime-portlet.css" />
        {code}
        But this wouldn't solve the problem entirely -- here is a fragment of CSS from rime-portlet.css:
        {code}
        input.iceSelInpDateOpenPopup, input.iceSelInpDateOpenPopup-dis {
            background-image: url(css-images/cal_button.gif);
        }
        {code}
        The problem here is that cal_button.gif is expected to live relative to the xp-rime.css file, in a URL like "/my-portlet/xmlhttp/css/rime/css-images/cal-button.gif" but you can't make that context-path-relative assumption with WSRP. To fix this problem, the #{resource} EL keyword would have to be used within the rime.css file for each image resource, something similar to this:
        {code}
        input.iceSelInpDateOpenPopup, input.iceSelInpDateOpenPopup-dis {
            background-image: url("#{resource['icefaces-rime-portlet:images/cal-button.gif']}");
        }
        {code}
        One workaround would be to deploy a lightweight webapp in the same server as the WSRP Consumer that contains the CompatResourceServlet and theme resources, but that doesn't exactly achieve what WSRP is trying to accomplish, which is to have the entire portlet (and it's resources) deployed to a remote portal server.
        ICEfaces 3.0.1 is generally working in Liferay Portal 6.1 WSRP and Liferay Faces Bridge, but ICEfaces 1.8 compatibility components like ice:selectInputDate aren't rendering properly.

        The problem stems from the fact that the 1.8 compatibility components rely on context-path relative URLs, rather than the JSF2 #{resource} EL keyword.

        For example, here is how the theme CSS is typically loaded in a portlet:
        {code}
        <link href="#{request.contextPath}/xmlhttp/css/rime/rime-portlet.css" rel="stylesheet" type="text/css"/>
        {code}
        ... and the rendered <link> tag typically looks like this:
        {code}
        <link href="/my-portlet/xmlhttp/css/rime/rime-portlet.css" rel="stylesheet" type="text/css"/>
        {code}
        This is a problem because it ultimately relies on the /my-portlet context-path of the request, which is not compatible with WSRP. If the xp-rime.css were able to be retrieved with the JSF2 h:outputStyleSheet component, then the WSRP problem would be solved, because it would be retrieved with a portlet ResourceURL that WSRP knows how to rewrite for the WSRP Consumer to download. Something like this:
        {code}
        <h:outputStyleSheet library="icefaces-rime-portlet" name="rime-portlet.css" />
        {code}
        But this wouldn't solve the problem entirely -- here is a fragment of CSS from rime-portlet.css:
        {code}
        input.iceSelInpDateOpenPopup, input.iceSelInpDateOpenPopup-dis {
            background-image: url(css-images/cal_button.gif);
        }
        {code}
        The problem here is that cal_button.gif is expected to live relative to the xp-rime.css file, in a URL like "/my-portlet/xmlhttp/css/rime/css-images/cal-button.gif" but you can't make that context-path-relative assumption with WSRP. To fix this problem, the #{resource} EL keyword would have to be used within the rime.css file for each image resource, something similar to this:
        {code}
        input.iceSelInpDateOpenPopup, input.iceSelInpDateOpenPopup-dis {
            background-image: url("#{resource['icefaces-rime-portlet:images/cal-button.gif']}");
        }
        {code}
        I thought that a workaround could be to deploy a lightweight webapp in the same server as the WSRP Consumer that contains the CompatResourceServlet and theme resources. But it isn't good enough, because the relative URLs from xp-rime.css would produce WSRP errors because they can't simply be appended to a wsrp_rewrite URL.
        Deryk Sinotte made changes -
        Salesforce Case []
        Fix Version/s EE-3.1.0.GA [ 10332 ]
        Assignee Deryk Sinotte [ deryk.sinotte ]
        Ken Fyten made changes -
        Workaround Description Suggestion is to avoid this issue by using the ICEfaces ACE components instead of the ICEfaces Compat components.
        Workaround Exists Yes [ 10007 ]
        Ken Fyten made changes -
        Fix Version/s EE-3.2.0.GA [ 10332 ]
        Ken Fyten made changes -
        Assignee Deryk Sinotte [ deryk.sinotte ]

          People

          • Assignee:
            Unassigned
            Reporter:
            Neil Griffin
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: