Using icefaces3 trunk, the initial page GET of the tutorial would never return from the server, and the log would show a PermGen memory exception. After a clean start of tomcat7 with the app, loading the page would always immediately cause the PermGen memory exception.

Exception in thread "http-bio-8080-exec-2" java.lang.OutOfMemoryError: PermGen space

After making the following changes, the problem still occured:

• Changed bean scope from request to session
• Changed EL to use a getter to access the callback, instead of the bean directly being a callback
• Commented out the MD5 digesting
• Removed, or made static some inner classes in the tutorial
• Removed some message bundle usage

Finally, simply removing more apps from the webapp folder stopped the PermGen exception, and allowed the page to load.

When uploading, the debug shows that it doesn't consider the upload submit to be multipart. The captureFileOnSubmit() javascript is being rendered, but doesn't appear to be doing the job, since the browser is just doing a full page post. This is due to a javascript exception in the file upload javascript:

jQuery is not defined
ace-components.js.jsf?ln=icefaces.ace()ace-co...ces.ace (line 1076)
[Break On This Error]

})(jQuery);

And that's likely due to the javascript collating not taking into account that fileEntry didn't rely on jquery separately, but the collated javascript now does, and FileEntryMeta doesn't have the jquery references.

Looking at the resource dependencies of another component, checkboxButton, it's a little confusing how the ace-jquery.js comes after the ace-yui.js, since one assumes it needs be the other way around.

@ResourceDependencies(

)

This error was in the POST response page, and did not show up in the log:

The server encountered an internal error () that prevented it from fulfilling this request.
java.lang.NullPointerException
com.sun.faces.context.PartialViewContextImpl.createPartialResponseWriter(PartialViewContextImpl.java:441)
com.sun.faces.context.PartialViewContextImpl.access$300(PartialViewContextImpl.java:71)
com.sun.faces.context.PartialViewContextImpl$DelayedInitPartialResponseWriter.getWrapped(PartialViewContextImpl.java:582)
javax.faces.context.PartialResponseWriter.startDocument(PartialResponseWriter.java:115)
org.icefaces.ace.context.CallbackPartialResponseWriter.startDocument(CallbackPartialResponseWriter.java:115)
com.sun.faces.context.AjaxExceptionHandlerImpl.handlePartialResponseError(AjaxExceptionHandlerImpl.java:199)
com.sun.faces.context.AjaxExceptionHandlerImpl.handle(AjaxExceptionHandlerImpl.java:123)
org.icefaces.impl.application.ExtendedExceptionHandler.handle(ExtendedExceptionHandler.java:104)
com.sun.faces.lifecycle.Phase.doPhase(Phase.java:119)
com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:594)

After removing all the extraneous compat jar, web.xml entries and ICEfaces 2 style CSS references, the app was re-deployed, and still gave the exact same error.

Using the ExtendedExceptionHandler, the exceptions it's trapping are:

ExtendedExceptionHandler: java.lang.NullPointerException
java.lang.NullPointerException
at org.icefaces.impl.event.FacesMessagesPhaseListener.beforePhase(FacesMessagesPhaseListener.java:98)
at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:228)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:99)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:928)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:539)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:300)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
ExtendedExceptionHandler: java.lang.NullPointerException
java.lang.NullPointerException
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:96)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:928)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:539)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:300)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)

The FacesMessagesPhaseListener exception is from the UIViewRoot being null.

From the debug:

FileEntryPhaseListener.afterPhase() RESTORE_VIEW 1
FileEntryPhaseListener.afterPhase() renderResponse : true
FileEntryPhaseListener.afterPhase() responseComplete: false

So, on file upload, something is happening in RestoreView that's causing responseComplete, and the UIViewRoot is null, which is messing up the FacesMessagePhaseListener.

Changing the FacesMessagePhaseListener, to handle the UIViewRoot being null has removed it from the list of exceptions, but the RenderResponsePhase remains, and from the source it also looks like a NPE for the UIViewRoot being null.

And the PartialViewContextImpl NPE that happens when trying to handle the RenderResponsePhase exception, is from the renderKit being null, which happens when the UIViewRoot is null.

The vestiges of commented out the MD5 digesting was causing the exception, since it did an invalidating of the form within the callback's end method. It looks like that messes up the JSF lifecycle. So, the status updating needs to happen later, in the fileEntryListener, and not the callback's end method. The example will need to be updated, and this should be documented in the wiki.

That specific updateStatus(FileEntryStatus, boolean invalidate) method exists for the callback. We've documented this whole time for the callback to use it. The problem is only with the invalidate flag also causing a renderResponse so early. If it only invalidates the form, then that will cause a renderResponse in ApplyRequestValues anyway. The only side-effect is that other components in the form will decode and have their submittedValues set if the callback fails.

Committed the change to FacesMessagePhaseListener to handle the UIViewRoot being null.

icefaces 3 trunk
Subversion 27721
icefaces 3.0.x maintenance
Subversion 27840

Changed the updateStatus methods so that if the invalidate parameter is true, then it will only call FacesContext.renderResponse() if the lifecycle phase is not RESTORE_VIEW.

icefaces 3 trunk
Subversion 27724
icefaces 3.0.x maintenance
Subversion 27841

Removed compat from the tutorial, and added a work-around for this issue into the tutorial, for when people use the tutorial with ICEfaces 3.0.0 and older.

icefaces 3 trunk
Subversion 27831
icefaces 3.0.x maintenance
Subversion 27846

Updated the Maven building to use ICEfaces 3.0.0 and to use the same build targets names as the README.html

icefaces 3 trunk
Subversion 27835
icefaces 3.0.x maintenance
Subversion 27847

As well, the tutorial wiki page was updated along with its standalone .zip download.
http://wiki.icefaces.org/display/ICE/Incremental+Upload+Processing+Using+FileEntryCallback