Attached test case. Needs icefaces.jar and icefaces-ace.jar added, as well as to be deployed into a Liferay 6.2 Tomcat server.

The NCI is caused by a malformed partial update. The update looks like this:

<partial-response id="_1_WAR_test_INSTANCE_szf78iTNW24i_">
    <changes>
        <update id="_1_WAR_test_INSTANCE_szf78iTNW24i_:f1">....</update>
        .....
        <update id="vvoouedh5-single-submit">....</update>
    </changes>
</partial-response>
<script type="text/javascript">
// <![CDATA[
ice.setupBridge('_1_WAR_test_INSTANCE_szf78iTNW24i_:vvoouedh5_icefaces_config', 'voouedh5', 'hpiidlgkjy'
, {reloadOnUpdateFailure: false,deltaSubmit: false,focusManaged: true,disableDefaultErrorPopups: false
,standardFormSerialization: false,sendDisposeWindow: false,blockUIOnSubmit: false,clientSideElementUpdateDetermination
: false,parameterPrefix: ''});ice.setupBridge('_1_WAR_test_INSTANCE_szf78iTNW24i_:vvoouedh5_icefaces_config'
, 'voouedh5', 'hpiidlgkjy', {reloadOnUpdateFailure: false,deltaSubmit: false,focusManaged: true,disableDefaultErrorPopups
: false,standardFormSerialization: false,sendDisposeWindow: false,blockUIOnSubmit: false,clientSideElementUpdateDetermination
: false,parameterPrefix: ''});ice.setupBridge('_1_WAR_test_INSTANCE_szf78iTNW24i_:vvoouedh5_icefaces_config'
, 'voouedh5', 'hpiidlgkjy', {reloadOnUpdateFailure: false,deltaSubmit: false,focusManaged: true,disableDefaultErrorPopups
: false,standardFormSerialization: false,sendDisposeWindow: false,blockUIOnSubmit: false,clientSideElementUpdateDetermination
: false,parameterPrefix: ''});
// ]]>
</script>

The ‘script’ tag containing code for setting up the bridge is outside the root element of the document. Also the bridge setup is invoked 4 times for some reason. The debugging points to com.liferay.faces.bridge.renderkit.html_basic.internal.BodyRendererBridgeImpl class who presumably is responsible for rendering resources contained by the body facet. ICEfaces adds to the body facet the bridge setup script as a resource.

I managed to successfully deploy the test app with the 4.2 bridge libraries. The NCI is still triggered but this time is caused by a partial update that targets an inexistent element. Debugging the server side where the DOM updates are prepared shows that the old DOM document that we keep around in the view map is not restored during a post-back. Because of that the prepared update is the entire new document (which has a root element that does not yet exist in the browser's DOM).

I was able to reproduce exactly what Mircea observed when he wrote:

The NCI is still triggered but this time is caused by a partial update that targets an inexistent element. Debugging the server side where the DOM updates are prepared shows that the old DOM document that we keep around in the view map is not restored during a post-back.

I spent some time in the debugger and found observed two things:
1. Everything works OK when doing a partial form submission, like changing the email address and tabbing-out of the field (which triggers server-side validation of the email address). In this case, the XHR parameters look like this:

javax.faces.partial.execute:_1_WAR_icefaces4portlet_INSTANCE_j2fWCwhiTOSl_:f1:emailAddress
javax.faces.partial.render:_1_WAR_icefaces4portlet_INSTANCE_j2fWCwhiTOSl_:f1:emailAddressField

2. When the form is submitted by clicking on the "Submit" button, the NCI error appears. In this case, the XHR parameters look like this:

javax.faces.partial.execute:@all
javax.faces.partial.render:@all

Now, the reason why DomResponseWriter.getOldDocument() returns null is because a navigation-rule fired (navigating from porltetViewMode.xhtml to confirmation.xhtml) which means there is a DIFFERENT UIViewRoot and ViewMap.

At this point I think the bridge is working correctly. ICEfaces needs to be able to realize that the rendered markup of the new confirmation.xhtml view needs to be replaced in the portlet's <div> which is what plain JSF does, thanks to a special response writer in the bridge. For more information, I highly recommend reading the JavaDoc comments starting at line #46 of ResponseWriterBridgeImpl.java

ICEfaces does propagate the old document from one view to another when a forward navigation is executed. In Liferay's case the ConfigurableNavigationHandler.getNavigationCase method returns null which blocks our PropagatingNavigationHandler from determining if there's a forward navigation executed and thus the propagation is not applied.

Applied fix to PropagatingNavigationHandler to always propagate the old document entry in the viewmap if Liferay is detected.

Hi Mircea,

I noticed in the diff that this will only be a fix for Liferay:
http://sventon.icesoft.org/svn/repos/repo/diff/icefaces4/trunk/icefaces/core/src/main/java/org/icefaces/impl/application/PropagatingNavigationHandler.java?revision=47037&entries=/icefaces4/trunk/icefaces/core/src/main/java/org/icefaces/impl/application/PropagatingNavigationHandler.java@47037&entries=/icefaces4/trunk/icefaces/core/src/main/java/org/icefaces/impl/application/PropagatingNavigationHandler.java@47036&showlatestrevinfo=true

-        if (navigationCase != null && !navigationCase.isRedirect()) {
+        if (EnvUtils.isLiferay() || (navigationCase != null && !navigationCase.isRedirect())) {

But we also do testing in Pluto, and JSR 378 will likely be tested by IBM with WebSphere Portal.

Could you make this more of a portlet-general fix rather than a Liferay-specific fix? Something like this:

        if (EnvUtils.isLiferay() || EnvUtils.isPlutoPortal() || EnvUtils.isWebSpherePortal() || (navigationCase != null && !navigationCase.isRedirect())) {

Thanks,

Neil

Hi Neil,

Yes, I can do that. It would be good thought to have a look at why the ConfigurableNavigationHandler.getNavigationCase method returns null.

Changed _ PropagatingNavigationHandler_to propagate viewmap entries between views in any of the supported portals.

Hi Mircea,

I did as you asked and spent some more time in the debugger. I think that the root of the problem is found here in PropagatingNavigationHandler.java:

wrapped.handleNavigation(context, fromAction, outcome);
viewRoot = context.getViewRoot();
NavigationCase navigationCase = getNavigationCase(context, fromAction, outcome);

If you move the call to getNavigationCase earlier then I think things will work correctly and you can remove the "if" check you added as a workaround:

NavigationCase navigationCase = getNavigationCase(context, fromAction, outcome);
wrapped.handleNavigation(context, fromAction, outcome);
viewRoot = context.getViewRoot();

The problem is that PropagatingNavigationHandler is calling the getNavigationCase method after the navigation to the new view has taken place. It needs to be called before the navigation takes place so that you can see what the actual matching navigation-case was prior to the navigation.

FWIW, We have a similar piece of code in the bridge found in BridgeNavigationHandlerImpl.java.

Neil

Changed PropagatingNavigationHandler to acquire navigation case before navigation is executed to ensure that a non-null value is returned. Removed portal specific workaround.

Thanks Neil.

Reopening due to NPE's seen when deploying to Liferay 6.2 the attached test case, or the showcase-portlet.war file built with icefaces.jar, icefaces-ace.jar and liferay-faces-*.jar from ICEfaces4 trunk r. 47097.

The two .war files have been placed here: \\iceads1.icesoft.domain\Users\carmen\ICE-10903\

19:32:09,913 INFO [com.liferay.portal.kernel.deploy.auto.AutoDeployScanner][BaseDeployer:863] Deploying icefaces4-portlet.war
19:32:10,652 INFO [com.liferay.portal.kernel.deploy.auto.AutoDeployScanner][BaseDeployer:2389] Modifying Servlet 3.0 C:\Servers\liferay-portal-6.2-ce-ga3\tomcat-7.0.42\temp\20160205193209916\WEB-INF\web.xml
19:32:11,049 INFO [com.liferay.portal.kernel.deploy.auto.AutoDeployScanner][PortletAutoDeployListener:91] Portlets for C:\Servers\liferay-portal-6.2-ce-ga3\deploy\icefaces4-portlet.war copied successfully. Deployment will start in a few seconds.
19:32:22,998 INFO [localhost-startStop-2][HotDeployEvent:145] Plugin icefaces4-portlet requires marketplace-portlet
19:32:22,999 INFO [localhost-startStop-2][HotDeployImpl:217] Deploying icefaces4-portlet from queue
19:32:22,999 INFO [localhost-startStop-2][PluginPackageUtil:1016] Reading plugin package for icefaces4-portlet
19:32:23,468 INFO [localhost-startStop-2][PortletHotDeployListener:344] Registering portlets for icefaces4-portlet
19:32:23,545 INFO [localhost-startStop-2][PortletHotDeployListener:492] 1 portlet for icefaces4-portlet is available for use
19:38:11,165 INFO [com.liferay.portal.kernel.deploy.auto.AutoDeployScanner][AutoDeployDir:204] Processing icefaces4-portlet.war
19:38:11,165 INFO [com.liferay.portal.kernel.deploy.auto.AutoDeployScanner][PortletAutoDeployListener:79] Copying portlets for C:\Servers\liferay-portal-6.2-ce-ga3\deploy\icefaces4-portlet.war
19:38:11,265 INFO [com.liferay.portal.kernel.deploy.auto.AutoDeployScanner][BaseDeployer:863] Deploying icefaces4-portlet.war
19:38:11,265 INFO [com.liferay.portal.kernel.deploy.auto.AutoDeployScanner][BaseDeployer:966] Updating ICEfaces4 Portlet from version 6.2.2 to version 6.2.2
19:38:11,795 INFO [com.liferay.portal.kernel.deploy.auto.AutoDeployScanner][BaseDeployer:2389] Modifying Servlet 3.0 C:\Servers\liferay-portal-6.2-ce-ga3\tomcat-7.0.42\temp\20160205193811265\WEB-INF\web.xml
19:38:12,105 INFO [com.liferay.portal.kernel.deploy.auto.AutoDeployScanner][PortletAutoDeployListener:91] Portlets for C:\Servers\liferay-portal-6.2-ce-ga3\deploy\icefaces4-portlet.war copied successfully. Deployment will start in a few seconds.
19:38:16,509 INFO [ContainerBackgroundProcessor[StandardEngine[Catalina]]][HotDeployEvent:145] Plugin icefaces4-portlet requires marketplace-portlet
19:38:16,639 INFO [ContainerBackgroundProcessor[StandardEngine[Catalina]]][PortletHotDeployListener:525] Unregistering portlets for icefaces4-portlet
19:38:16,649 INFO [ContainerBackgroundProcessor[StandardEngine[Catalina]]][PortletHotDeployListener:560] 1 portlet for icefaces4-portlet was unregistered
19:38:16,650 INFO [ContainerBackgroundProcessor[StandardEngine[Catalina]]][PluginPackageUtil:1016] Reading plugin package for icefaces4-portlet
19:38:19,550 INFO [ContainerBackgroundProcessor[StandardEngine[Catalina]]][HotDeployEvent:145] Plugin icefaces4-portlet requires marketplace-portlet
19:38:19,550 INFO [ContainerBackgroundProcessor[StandardEngine[Catalina]]][HotDeployImpl:217] Deploying icefaces4-portlet from queue
19:38:19,550 INFO [ContainerBackgroundProcessor[StandardEngine[Catalina]]][PluginPackageUtil:1016] Reading plugin package for icefaces4-portlet
19:38:20,260 INFO [ContainerBackgroundProcessor[StandardEngine[Catalina]]][PortletHotDeployListener:344] Registering portlets for icefaces4-portlet
19:38:20,407 ERROR [ContainerBackgroundProcessor[StandardEngine[Catalina]]][PortletBagFactory:340] java.lang.NullPointerException
java.lang.NullPointerException
at com.liferay.faces.util.config.ApplicationConfigInitializerImpl.newResourceReader(ApplicationConfigInitializerImpl.java:90)
at com.liferay.faces.util.config.ApplicationConfigInitializerImpl.initialize(ApplicationConfigInitializerImpl.java:48)
at com.liferay.faces.util.config.ApplicationConfigUtil.initializeApplicationConfig(ApplicationConfigUtil.java:38)
at com.liferay.faces.bridge.BridgeImpl.init(BridgeImpl.java:168)
at javax.portlet.faces.GenericFacesPortlet.init(GenericFacesPortlet.java:97)
at com.liferay.portlet.InvokerPortletImpl.init(InvokerPortletImpl.java:269)
at com.liferay.portlet.PortletInstanceFactoryImpl.init(PortletInstanceFactoryImpl.java:228)
at com.liferay.portlet.PortletInstanceFactoryImpl.create(PortletInstanceFactoryImpl.java:145)
at com.liferay.portlet.PortletInstanceFactoryUtil.create(PortletInstanceFactoryUtil.java:41)
at com.liferay.portlet.PortletBagFactory.create(PortletBagFactory.java:337)
at com.liferay.portal.deploy.hot.PortletHotDeployListener.doInvokeDeploy(PortletHotDeployListener.java:370)
at com.liferay.portal.deploy.hot.PortletHotDeployListener.invokeDeploy(PortletHotDeployListener.java:125)
at com.liferay.portal.deploy.hot.HotDeployImpl.doFireDeployEvent(HotDeployImpl.java:227)
at com.liferay.portal.deploy.hot.HotDeployImpl.fireDeployEvent(HotDeployImpl.java:96)
at com.liferay.portal.kernel.deploy.hot.HotDeployUtil.fireDeployEvent(HotDeployUtil.java:28)
at com.liferay.portal.kernel.servlet.PluginContextListener.fireDeployEvent(PluginContextListener.java:164)
at com.liferay.portal.kernel.servlet.PluginContextListener.doPortalInit(PluginContextListener.java:154)
at com.liferay.portal.kernel.util.BasePortalLifecycle.portalInit(BasePortalLifecycle.java:44)
at com.liferay.portal.kernel.util.PortalLifecycleUtil.register(PortalLifecycleUtil.java:74)
at com.liferay.portal.kernel.util.PortalLifecycleUtil.register(PortalLifecycleUtil.java:58)
at com.liferay.portal.kernel.util.BasePortalLifecycle.registerPortalLifecycle(BasePortalLifecycle.java:54)
at com.liferay.portal.kernel.servlet.PluginContextListener.contextInitialized(PluginContextListener.java:116)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4939)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5434)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.StandardContext.reload(StandardContext.java:3954)
at org.apache.catalina.startup.HostConfig.checkResources(HostConfig.java:1270)
at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1439)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:315)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1374)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1530)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1540)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1519)
at java.lang.Thread.run(Thread.java:744)
19:38:20,416 ERROR [ContainerBackgroundProcessor[StandardEngine[Catalina]]][HotDeployImpl:230] com.liferay.portal.kernel.deploy.hot.HotDeployException: Error registering portlets for icefaces4-portleticefaces4-portlet
com.liferay.portal.kernel.deploy.hot.HotDeployException: Error registering portlets for icefaces4-portleticefaces4-portlet
at com.liferay.portal.kernel.deploy.hot.BaseHotDeployListener.throwHotDeployException(BaseHotDeployListener.java:46)
at com.liferay.portal.deploy.hot.PortletHotDeployListener.invokeDeploy(PortletHotDeployListener.java:128)
at com.liferay.portal.deploy.hot.HotDeployImpl.doFireDeployEvent(HotDeployImpl.java:227)
at com.liferay.portal.deploy.hot.HotDeployImpl.fireDeployEvent(HotDeployImpl.java:96)
at com.liferay.portal.kernel.deploy.hot.HotDeployUtil.fireDeployEvent(HotDeployUtil.java:28)
at com.liferay.portal.kernel.servlet.PluginContextListener.fireDeployEvent(PluginContextListener.java:164)
at com.liferay.portal.kernel.servlet.PluginContextListener.doPortalInit(PluginContextListener.java:154)
at com.liferay.portal.kernel.util.BasePortalLifecycle.portalInit(BasePortalLifecycle.java:44)
at com.liferay.portal.kernel.util.PortalLifecycleUtil.register(PortalLifecycleUtil.java:74)
at com.liferay.portal.kernel.util.PortalLifecycleUtil.register(PortalLifecycleUtil.java:58)
at com.liferay.portal.kernel.util.BasePortalLifecycle.registerPortalLifecycle(BasePortalLifecycle.java:54)
at com.liferay.portal.kernel.servlet.PluginContextListener.contextInitialized(PluginContextListener.java:116)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4939)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5434)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.StandardContext.reload(StandardContext.java:3954)
at org.apache.catalina.startup.HostConfig.checkResources(HostConfig.java:1270)
at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1439)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:315)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1374)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1530)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1540)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1519)
at java.lang.Thread.run(Thread.java:744)
Caused by: java.lang.NullPointerException
at com.liferay.faces.util.config.ApplicationConfigInitializerImpl.newResourceReader(ApplicationConfigInitializerImpl.java:90)
at com.liferay.faces.util.config.ApplicationConfigInitializerImpl.initialize(ApplicationConfigInitializerImpl.java:48)
at com.liferay.faces.util.config.ApplicationConfigUtil.initializeApplicationConfig(ApplicationConfigUtil.java:38)
at com.liferay.faces.bridge.BridgeImpl.init(BridgeImpl.java:168)
at javax.portlet.faces.GenericFacesPortlet.init(GenericFacesPortlet.java:97)
at com.liferay.portlet.InvokerPortletImpl.init(InvokerPortletImpl.java:269)
at com.liferay.portlet.PortletInstanceFactoryImpl.init(PortletInstanceFactoryImpl.java:228)
at com.liferay.portlet.PortletInstanceFactoryImpl.create(PortletInstanceFactoryImpl.java:145)
at com.liferay.portlet.PortletInstanceFactoryUtil.create(PortletInstanceFactoryUtil.java:41)
at com.liferay.portal.deploy.hot.PortletHotDeployListener.initPortletApp(PortletHotDeployListener.java:622)
at com.liferay.portal.deploy.hot.PortletHotDeployListener.doInvokeDeploy(PortletHotDeployListener.java:377)
at com.liferay.portal.deploy.hot.PortletHotDeployListener.invokeDeploy(PortletHotDeployListener.java:125)
... 24 more

Hi Carmen,

Are you able to provide me with access to the WARs? I'd be happy to take a look at the problem.

Thanks,

Neil

Neil,

I pushed out the ICEfaces 4.1.1-SNAPSHOT to our maven2 snapshots repo for you: http://anonsvn.icesoft.org/repo/maven2/snapshots/

You can use those libs with the test case from this JIRA to reproduce.

Thx!
Ken

Possible test configuration issue on our end Neil, we are retesting currently.

The NCI still can be reproduced after replacing in the test case only the icefaces.jar and icefaces-ace.jar from 4.1.1 release, but not from IF4 trunk r. 47097.

I placed the two .war files, one built with the IF4 trunk libraries (icefaces4-portlet-410.war), and another with the 4.1.1 release libs (icefaces4-portlet-411.war) under \\iceads1\Public\users\carmen\ICE-10903\ .

I could not reproduce the NullPointerException nor the NCI popup. For testing I used both WAR files provided at \\iceads1\Public\users\carmen\ICE-10903\ .

On the other hand, after filling and submitting the test form the navigation would not occur. No errors or exceptions would be shown.

Well, it seems the test WARs did not include the correct Liferay Bridge libraries. Both 4.1.1 and 4.0 test cases will work as expected once the following libraries are used:

http://central.maven.org/maven2/com/liferay/faces/liferay-faces-alloy/4.2.5-ga6/liferay-faces-alloy-4.2.5-ga6.jar
http://central.maven.org/maven2/com/liferay/faces/liferay-faces-bridge-api/4.2.5-ga6/liferay-faces-bridge-api-4.2.5-ga6.jar
http://central.maven.org/maven2/com/liferay/faces/liferay-faces-bridge-impl/4.2.5-ga6/liferay-faces-bridge-impl-4.2.5-ga6.jar
http://central.maven.org/maven2/com/liferay/faces/liferay-faces-util/4.2.5-ga6/liferay-faces-util-4.2.5-ga6.jar

Thanks, Mircea, for the instructions on which liferay jars to be used.

Verified ICEfaces 4.1.1 release libraries and IF4 trunk r. 47097 on IE11, FF41, Chrome48 with the attached test app, and none of the errors previously reported could be reproduced; also, the form navigation occurs on form submit.

Verified ICEfaces4 trunk r. 47596 on IE11, CFF41, Chrome48 with attached test case.
The following jars are used:
liferay-faces-alloy-2.0.0-SNAPSHOT.jar
liferay-faces-bridge-api-4.0.0-SNAPSHOT.jar
liferay-faces-bridge-ext-3.0.0-SNAPSHOT.jar
liferay-faces-bridge-impl-4.0.0-SNAPSHOT.jar
liferay-faces-util-3.0.0-SNAPSHOT.jar