ICEfaces
  1. ICEfaces
  2. ICE-5281

ICEfaces push does not work if first contact with application is directly to the .jsf page

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0-Alpha2
    • Fix Version/s: 2.0-Alpha2, 2.0.0
    • Component/s: Framework
    • Labels:
      None
    • Environment:
      ICEfaces 2, Alpha 2 pre-release, auction sample, Tomcat 6, all browsers.

      Description

      When running the auction sample, if your first navigation to the application in the browser is directly to http://localhost:8080/auction/auction.jsf, then the push updates will not work/initialize correctly. You only receive ping updates, no actual push events. This problem last for the life of that session, so you need to restart the browser to clear the session to correct it.

      If you initially land on the http://localhost:8080/auction/ URL instead, then push will work correctly.

        Activity

        Hide
        Deryk Sinotte added a comment -

        It appears that the issue is related to a valid session being available. The two URLs actually slightly different code paths. Going to the /auction/ context actually requests auction/index.jsp which redirects to auction/auction.jsf. This initial request appears to ensure that a session has been created.

        Going directly to auction/auction.jsf appears to do session creation more lazily and is not available when the WindowScopeManager.lookup method needs it. Enforcing session creation in this method seems to fix the problem:

        public synchronized static WindowScopeManager lookup(FacesContext context)

        { ExternalContext externalContext = context.getExternalContext(); //ICE-5281: We require that a session be available at this point and it may not have // been created otherwise. Object session = externalContext.getSession(true); Map sessionMap = externalContext.getSessionMap(); ExternalContextConfiguration configuration = new ExternalContextConfiguration("org.icefaces", externalContext); return lookup(sessionMap, configuration); }

        The side effect is tha,t since JSF 2.0 encodes all the URLs with jsessionid in case cookies are not supported, the first push update does a fairly major update to the page which causes some flicker.

        Show
        Deryk Sinotte added a comment - It appears that the issue is related to a valid session being available. The two URLs actually slightly different code paths. Going to the /auction/ context actually requests auction/index.jsp which redirects to auction/auction.jsf. This initial request appears to ensure that a session has been created. Going directly to auction/auction.jsf appears to do session creation more lazily and is not available when the WindowScopeManager.lookup method needs it. Enforcing session creation in this method seems to fix the problem: public synchronized static WindowScopeManager lookup(FacesContext context) { ExternalContext externalContext = context.getExternalContext(); //ICE-5281: We require that a session be available at this point and it may not have // been created otherwise. Object session = externalContext.getSession(true); Map sessionMap = externalContext.getSessionMap(); ExternalContextConfiguration configuration = new ExternalContextConfiguration("org.icefaces", externalContext); return lookup(sessionMap, configuration); } The side effect is tha,t since JSF 2.0 encodes all the URLs with jsessionid in case cookies are not supported, the first push update does a fairly major update to the page which causes some flicker.

          People

          • Assignee:
            Deryk Sinotte
            Reporter:
            Ken Fyten
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: