ICEfaces
  1. ICEfaces
  2. ICE-6851

The {{command}} replacement strategy doesn't work with WebSphere 7 Portal stateful URLs

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.1, EE-2.0.0.GA
    • Fix Version/s: 2.1-Beta, 3.0, EE-2.0.0.GA_P01
    • Component/s: Bridge, Framework
    • Labels:
      None
    • Environment:
      ICEfaces 2 WebSphere Portal 7

      Description

      Initially logging into a WebSphere 7 portal page results in this kind of URL:

      http://192.168.55.111:10039/wps/myportal/!ut/p/b1/04_Sj9CPykssy0xPLMnMz0vM0Q90LSrKLwpOLS4G8kMyc1PzS0tAiqLM4p3dHT1MzH0MDCxMLQwNPB09Qs3Ngl2MDFzN9cP1o_AqCTSBKjDAARwN9P2w2VyQ4eVR7qioCAABx-t_/dl4/d5/L3dJdyEvUUd3SndBQSEvNEprRS9aNl8wMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDBBMA!!/

      In the resulting page markup, the ICEpush configuration info looks like this:

      <span id="A1176:v2fvcng6_icepush">
          <script type="text/javascript">ice.push.configuration.contextPath="/";ice.push.configuration.uriPattern="/wps/myportal/Home/chat/!ut/p/b1/hY7BjoIwFEW_xS94r1KgLhslClQHBgHphhBSlYkK0xYS_fpxJrM13t1NTu49IKEi_oL4jLgMDiBvzdSdGtv1t-by26VXo5c4iVi6NF5_uhjmdLeKaEQQCZQg_5Dlmm-oLxCZywiGfJP7XraaY0r_AXwRjm8WuAO7QOteZ8qYp9W-u6p-tM_nSvov1dgcSq1MP-pWQdo27VkJNalL0pwUZHBAWmdfbIhFMBoMrNgH1JLOxqKlk8iHD1IttrEZtlleF_e7Lh9OkRc85TZ6fNN0NoOrjIKjqsIf4eBGPw!!/";
          </script>
      </span>

      Using Firebug, you can see that the initial request to get the bridge.js file is:

      http://192.168.55.111:10039/wps/myportal/Home/chat/!ut/p/b1/dY3NjoIwFEafxSe4t1AoLBskIlQHhilIN6QhjTIRYaCS6NPPT2br2X3JyXdAQRN66LOQOQ6cQN302p-17cebvv5u5bfo524uIo9mu3cP95IetylNCSKBGtSfEu14QplADLyA4J4nkvnl1kHu_gv4Ao5wTMbB_Dw1ir1MBQ7Us1nG-9wZKDrdXYwwq7nm-myghBPStvwMpkzE9wVjKz5iaklvM9HRVcjpjTThIVumQynb6vGY66dbyYoX3KbPL1psNjCoNHGHiH8DL6JcbQ!!/

      The original request to get icepush.js is:

      http://192.168.55.111:10039/wps/myportal/Home/chat/!ut/p/b1/dY3LDoIwFES_xS-4t1AoLBtAECqiiEo3pGkaxYioIN_vI26d3ZmczICE2nfQZT6zLDiAvKqpPaqx7a_q8mHpNugWdiECh2bxxsFFRfMwpSlBJLAH-VWCmCeUCUTP8QgueFIxtwwt5PZPwD_hCHnSd-a9VEv298qzYP8wQ_98aANrrfTJCDOZS6GOBko4IG3Ks3fLRPQcMBrFNqIjacdMaDqJ6rYidbP8dFlgr3A53Mngk918HfHY5PNQz6CTaWJ3AX8BX6pOrQ!!/

      The ICEpush config on the page is set to use the same URL as it did for getting the ICEfaces bridge:

      <span id="A1176:v2fvcngc_icepush">
          <script type="text/javascript">ice.push.configuration.contextPath="/";ice.push.configuration.uriPattern="/wps/myportal/Home/chat/!ut/p/b1/dY3NjoIwFEafxSe4t1AoLBskIlQHhilIN6QhjTIRYaCS6NPPT2br2X3JyXdAQRN66LOQOQ6cQN302p-17cebvv5u5bfo524uIo9mu3cP95IetylNCSKBGtSfEu14QplADLyA4J4nkvnl1kHu_gv4Ao5wTMbB_Dw1ir1MBQ7Us1nG-9wZKDrdXYwwq7nm-myghBPStvwMpkzE9wVjKz5iaklvM9HRVcjpjTThIVumQynb6vGY66dbyYoX3KbPL1psNjCoNHGHiH8DL6JcbQ!!/";
          </script>
      </span>

      On Liferay, the ICEpush configuration results in something like this:

      <span id="A9944:v9iqym2_icepush">
          <script type="text/javascript">/*&lt;![CDATA[*/ice.push.configuration.contextPath="/";ice.push.configuration.uriPattern="/web/guest/chat1?_chatice2portlet_WAR_chatportlet_INSTANCE_nh4N_javax.faces.resource={{command}}&amp;p_p_cacheability=cacheLevelPage&amp;p_p_col_count=1&amp;p_p_col_id=column-1&amp;p_p_id=chatice2portlet_WAR_chatportlet_INSTANCE_nh4N&amp;p_p_lifecycle=2&amp;p_p_mode=view&amp;p_p_state=normal";/*]]&gt;*/
          </script>
      </span>

      It seems likely that this is all related to WebSphere Portal 7's own support for back button history in that a bunch of state is encoded into URLs. Not sure it's playing nice with what we want to do. For example, we replace the {{command}} marker dynamically in the URL but once it's been encoded by WebSphere, it's no longer there to be replaced.

      From WebSphere's own documentation:

      "Considerations for administrators about Back button behavior
      The Back button behavior of the portal is internally achieved by coding the combination of all states into the address of the view, that is into its URL. Thus each different combination of navigational states results in a different URL. This has the following additional advantages:

      Users can set separate bookmarks for different states of the same page.
      You can have pages cached by configuring specific requirements. For more details about how to do this, refer to Caching.
      However, make no assumptions about the syntax or structure of portal URLs. For example, you cannot create valid URLs by simple concatenation. This will automatically be true if only the public API is used to create URLs. The latest version of the IBM Portlet API Javadoc is always available from the WebSphere Portal Product Documentation page."

        Activity

          People

          • Assignee:
            Mircea Toma
            Reporter:
            Deryk Sinotte
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: