Ken Fyten added a comment - 29/Aug/13 2:38 PM Marking fixed pending LiferayFaces 3.1.3-ga4 final release.

Deryk Sinotte added a comment - 13/Aug/13 3:14 PM 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.

Deryk Sinotte added a comment - 08/Jul/13 4:49 PM 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

Deryk Sinotte added a comment - 02/Jul/13 2:45 PM 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.

Deryk Sinotte added a comment - 02/Jul/13 2:40 PM Screen shot showing Ajax response with SessionExpiredException along with the page that Liferay renders when it detects an exception.