ICEfaces
  1. ICEfaces
  2. ICE-9354

Portlets showing Network Connected Interrupt Dialog when session expires

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 3.3, EE-3.3.0.GA
    • Fix Version/s: EE-3.3.0.GA_P01, 4.0.BETA, 4.0
    • Component/s: Framework
    • Labels:
      None
    • Environment:
      Portlets
    • Assignee Priority:
      P1

      Description

      It only seems to be an issue with portlets but when the session expires, I'm seeing the Network Connection Interrupted popup appear. Logging on the server indicates that session expiry has occurred. I have not been able to see the same issue in non-portlet environment.

        Activity

        Hide
        Ken Fyten added a comment -

        Marking fixed pending LiferayFaces 3.1.3-ga4 final release.

        Show
        Ken Fyten added a comment - Marking fixed pending LiferayFaces 3.1.3-ga4 final release.
        Hide
        Deryk Sinotte added a comment -

        This has been verified to be fixed using a SNAPSHOT of LiferayFaces 3.1.3-ga4 (specifically 3.1.3-ga4-20130810.205323-5). Will leave this open until we have a production version that includes this fix.

        Show
        Deryk Sinotte added a comment - This has been verified to be fixed using a SNAPSHOT of LiferayFaces 3.1.3-ga4 (specifically 3.1.3-ga4-20130810.205323-5). Will leave this open until we have a production version that includes this fix.
        Hide
        Deryk Sinotte added a comment -

        Passed the information on to Neil who opened up a ticket in the Liferay system for this issue:

        http://issues.liferay.com/browse/FACES-1639

        Show
        Deryk Sinotte added a comment - Passed the information on to Neil who opened up a ticket in the Liferay system for this issue: http://issues.liferay.com/browse/FACES-1639
        Hide
        Deryk Sinotte added a comment -

        It seems that the exception is being detected by the Liferay container itself which ends up writing out the original Ajax update as well as the full page of the status portlet response (see the attached screen shot). I wouldn't have thought that Liferay would even see these exceptions as part of the Ajax request/response so I decided to concentrate on that and found a couple of things:

        • The LiferayFaces Bridge has the ExceptionHandlerAjaxImpl logging all the Ajax exceptions as a troubleshooting tool. We have something similar in our own custom exception handler when we found that Mojarra wasn't logging anything and certain problems related to Ajax were difficult to pin down.

        However, we switched to only doing it when ProjectStage = Development to avoid logging what amounts to normal behaviour (like ViewExpiredExceptions). This is not part of the current issue we're seeing but it does tend to generate some extra noise that you may not want in a production environment. So I modified the bridge's ExceptionHandlerAjaxImpl to do something similar:

                public void handle() throws FacesException {
         
        +        FacesContext fc = FacesContext.getCurrentInstance();
        +        boolean isDevelopment = fc.isProjectStage(ProjectStage.Development);
        +
                        // Before delegating, log all exceptions to the console.
                        Iterable<ExceptionQueuedEvent> unhandledExceptionQueuedEvents = getUnhandledExceptionQueuedEvents();
                        Iterator<ExceptionQueuedEvent> itr = unhandledExceptionQueuedEvents.iterator();
        @@ -58,7 +63,7 @@ public class ExceptionHandlerAjaxImpl extends ExceptionHandlerWrapper {
                                if (exceptionQueuedEventContext != null) {
                                        Throwable throwable = exceptionQueuedEventContext.getException();
         
        -                               if (throwable != null) {
        +                               if (throwable != null && isDevelopment) {
                                                logger.error(throwable);
                                        }
        
        • The real problem seems to be in BridgePhaseResourceImpl (again, a class in the LiferayFaces Bridge) where exceptions are detected, wrapped, and rethrown as BridgeExceptions. This causes them to trickle up to the container (Liferay) which does it's own error handling and sticks the "status" page onto the end of the Ajax response. To verify this, I made a slight alteration so that the extra wrapping is only done if this is not currently an Ajax request:
        +                //Only wrap/throw BridgeExceptions if it's not Ajax
        +                boolean isAjax = facesContext.getPartialViewContext().isAjaxRequest();
        +                logger.info("is Ajax: " + isAjax);
        +
        -                               if (handledException != null) {
        +                               if (handledException != null && !isAjax) {
                                                throw new BridgeException(handledException);
                                        }
         
                                        // Otherwise, if there were any "unhandled" exceptions queued, then throw a BridgeException.
                                        Throwable unhandledException = getJSF2UnhandledException(facesContext);
         
        -                               if (unhandledException != null) {
        +                               if (unhandledException != null && !isAjax) {
                                                throw new BridgeException(unhandledException);
                                        }
        

        I'll follow up with Neil about what we will do about these two issues and create/link additional JIRAs as required.

        Show
        Deryk Sinotte added a comment - It seems that the exception is being detected by the Liferay container itself which ends up writing out the original Ajax update as well as the full page of the status portlet response (see the attached screen shot). I wouldn't have thought that Liferay would even see these exceptions as part of the Ajax request/response so I decided to concentrate on that and found a couple of things: The LiferayFaces Bridge has the ExceptionHandlerAjaxImpl logging all the Ajax exceptions as a troubleshooting tool. We have something similar in our own custom exception handler when we found that Mojarra wasn't logging anything and certain problems related to Ajax were difficult to pin down. However, we switched to only doing it when ProjectStage = Development to avoid logging what amounts to normal behaviour (like ViewExpiredExceptions). This is not part of the current issue we're seeing but it does tend to generate some extra noise that you may not want in a production environment. So I modified the bridge's ExceptionHandlerAjaxImpl to do something similar: public void handle() throws FacesException { + FacesContext fc = FacesContext.getCurrentInstance(); + boolean isDevelopment = fc.isProjectStage(ProjectStage.Development); + // Before delegating, log all exceptions to the console. Iterable<ExceptionQueuedEvent> unhandledExceptionQueuedEvents = getUnhandledExceptionQueuedEvents(); Iterator<ExceptionQueuedEvent> itr = unhandledExceptionQueuedEvents.iterator(); @@ -58,7 +63,7 @@ public class ExceptionHandlerAjaxImpl extends ExceptionHandlerWrapper { if (exceptionQueuedEventContext != null) { Throwable throwable = exceptionQueuedEventContext.getException(); - if (throwable != null) { + if (throwable != null && isDevelopment) { logger.error(throwable); } The real problem seems to be in BridgePhaseResourceImpl (again, a class in the LiferayFaces Bridge) where exceptions are detected, wrapped, and rethrown as BridgeExceptions. This causes them to trickle up to the container (Liferay) which does it's own error handling and sticks the "status" page onto the end of the Ajax response. To verify this, I made a slight alteration so that the extra wrapping is only done if this is not currently an Ajax request: + //Only wrap/throw BridgeExceptions if it's not Ajax + boolean isAjax = facesContext.getPartialViewContext().isAjaxRequest(); + logger.info("is Ajax: " + isAjax); + - if (handledException != null) { + if (handledException != null && !isAjax) { throw new BridgeException(handledException); } // Otherwise, if there were any "unhandled" exceptions queued, then throw a BridgeException. Throwable unhandledException = getJSF2UnhandledException(facesContext); - if (unhandledException != null) { + if (unhandledException != null && !isAjax) { throw new BridgeException(unhandledException); } I'll follow up with Neil about what we will do about these two issues and create/link additional JIRAs as required.
        Hide
        Deryk Sinotte added a comment -

        Screen shot showing Ajax response with SessionExpiredException along with the page that Liferay renders when it detects an exception.

        Show
        Deryk Sinotte added a comment - Screen shot showing Ajax response with SessionExpiredException along with the page that Liferay renders when it detects an exception.

          People

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

            Dates

            • Created:
              Updated:
              Resolved: