ICEfaces
  1. ICEfaces
  2. ICE-1093

standardRequestScope causing lost connections

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.5.1
    • Fix Version/s: 1.5.2
    • Component/s: Framework
    • Labels:
      None
    • Environment:
      Operating System: Windows XP
      Platform: PC

      Description

      The com.icesoft.faces.standardRequestScope setting doesn't seem to be working.
      Tested with both concurrentDOMViews true and false. Also checked the forum and
      this was reported by one user: http://www.icefaces.org/JForum/posts/list/2672.page

        Activity

        Philip Breau created issue -
        Hide
        Ken Fyten added a comment -

        Raised priority based on Philip's input.

        Show
        Ken Fyten added a comment - Raised priority based on Philip's input.
        Hide
        Ted Goddard added a comment -

        Checked in the following change to ICEfaces 1.5 and head

        — core/src/com/icesoft/faces/webapp/xmlhttp/BlockingServlet.java (revision 12748)
        +++ core/src/com/icesoft/faces/webapp/xmlhttp/BlockingServlet.java (working copy)
        @@ -184,6 +184,7 @@
        if (PFstate.facesContext instanceof BridgeFacesContext) {
        BridgeFacesContext facesContext =
        (BridgeFacesContext) PFstate.facesContext;
        + facesContext.setCurrentInstance();
        bridgeExternalContext =
        (BridgeExternalContext) facesContext
        .getExternalContext();

        There is a caveat with this feature: f:loadBundle does not work with standardRequestScope because
        f:loadBundle is a JSP tag and only executes once under ICEfaces. The recommended approach is to
        create a new component ice:loadBundle that inserts the resource bundle into the request map each time
        upon rendering. (Should the bundle be applied to the request map upon encoding? Perhaps. Note that
        upon encoding is not sufficient as server-initiated renders do not include an encode invocation.)

        Show
        Ted Goddard added a comment - Checked in the following change to ICEfaces 1.5 and head — core/src/com/icesoft/faces/webapp/xmlhttp/BlockingServlet.java (revision 12748) +++ core/src/com/icesoft/faces/webapp/xmlhttp/BlockingServlet.java (working copy) @@ -184,6 +184,7 @@ if (PFstate.facesContext instanceof BridgeFacesContext) { BridgeFacesContext facesContext = (BridgeFacesContext) PFstate.facesContext; + facesContext.setCurrentInstance(); bridgeExternalContext = (BridgeExternalContext) facesContext .getExternalContext(); There is a caveat with this feature: f:loadBundle does not work with standardRequestScope because f:loadBundle is a JSP tag and only executes once under ICEfaces. The recommended approach is to create a new component ice:loadBundle that inserts the resource bundle into the request map each time upon rendering. (Should the bundle be applied to the request map upon encoding? Perhaps. Note that upon encoding is not sufficient as server-initiated renders do not include an encode invocation.)
        Hide
        Ted Goddard added a comment -

        verified that standardRequestScope does not cause lost connections (but also breaks f:loadBundle).

        Show
        Ted Goddard added a comment - verified that standardRequestScope does not cause lost connections (but also breaks f:loadBundle).
        Icefaces Administrator made changes -
        Field Original Value New Value
        issue.field.bugzillaimportkey 1123 12362
        Ken Fyten made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

          • Assignee:
            Ted Goddard
            Reporter:
            Philip Breau
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: