ICEfaces
  1. ICEfaces
  2. ICE-10903

NCI errors when testing Liferay 6.2 w/ LiferayFacesBridge 4.0

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 4.1
    • Fix Version/s: 4.1.1
    • Component/s: Bridge, Framework
    • Labels:
      None
    • Environment:
      ICEfaces 4.1, Liferay 6.2, LiferayFacesBridge 4.0
    • Assignee Priority:
      P1

      Description

      Using Liferay's test app (attached) which includes ICEfaces 4.1 and the LIferayfacesBridge 4.0 libs they are seeing NCI errors.

      We need to deploy this to a tomcat/Liferay 6.2 server and investigate.

        Issue Links

          Activity

          Ken Fyten created issue -
          Ken Fyten made changes -
          Field Original Value New Value
          Assignee Mircea Toma [ mircea.toma ]
          Fix Version/s 4.1 [ 11375 ]
          Assignee Priority P1 [ 10010 ]
          Hide
          Ken Fyten added a comment -

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

          Show
          Ken Fyten added a comment - Attached test case. Needs icefaces.jar and icefaces-ace.jar added, as well as to be deployed into a Liferay 6.2 Tomcat server.
          Ken Fyten made changes -
          Hide
          Mircea Toma added a comment -

          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.

          Show
          Mircea Toma added a comment - 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.
          Ken Fyten made changes -
          Security Private [ 10001 ]
          Ken Fyten made changes -
          Fix Version/s 4.1.1 [ 12972 ]
          Fix Version/s 4.1 [ 11375 ]
          Hide
          Mircea Toma added a comment -

          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).

          Show
          Mircea Toma added a comment - 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).
          Hide
          Neil Griffin added a comment -

          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

          Show
          Neil Griffin added a comment - 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
          Repository Revision Date User Message
          ICEsoft Public SVN Repository #47037 Thu Jan 28 04:27:51 MST 2016 mircea.toma ICE-10903 Always propagate viewmap between views in Liferay.
          Files Changed
          Commit graph MODIFY /icefaces4/trunk/icefaces/core/src/main/java/org/icefaces/impl/application/PropagatingNavigationHandler.java
          Hide
          Mircea Toma added a comment -

          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.

          Show
          Mircea Toma added a comment - 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.
          Mircea Toma made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Hide
          Neil Griffin added a comment -

          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

          Show
          Neil Griffin added a comment - 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
          Hide
          Mircea Toma added a comment -

          Hi Neil,

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

          Show
          Mircea Toma added a comment - Hi Neil, Yes, I can do that. It would be good thought to have a look at why the ConfigurableNavigationHandler.getNavigationCase method returns null.
          Hide
          Mircea Toma added a comment - - edited

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

          Show
          Mircea Toma added a comment - - edited Changed _ PropagatingNavigationHandler_to propagate viewmap entries between views in any of the supported portals.
          Repository Revision Date User Message
          ICEsoft Public SVN Repository #47041 Thu Jan 28 15:29:10 MST 2016 mircea.toma ICE-10903 Propagate viewmap between views in any of the supported portals.
          Files Changed
          Commit graph MODIFY /icefaces4/trunk/icefaces/core/src/main/java/org/icefaces/util/EnvUtils.java
          Commit graph MODIFY /icefaces4/trunk/icefaces/core/src/main/java/org/icefaces/impl/application/PropagatingNavigationHandler.java
          Hide
          Neil Griffin added a comment -

          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

          Show
          Neil Griffin added a comment - 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
          Ken Fyten made changes -
          Resolution Fixed [ 1 ]
          Status Resolved [ 5 ] Reopened [ 4 ]
          Hide
          Mircea Toma added a comment - - edited

          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.

          Show
          Mircea Toma added a comment - - edited 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.
          Mircea Toma made changes -
          Status Reopened [ 4 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Repository Revision Date User Message
          ICEsoft Public SVN Repository #47070 Wed Feb 03 14:23:01 MST 2016 mircea.toma ICE-10903 Acquire navigation case before navigation is executed to ensure that a non-null value is returned.
          Files Changed
          Commit graph MODIFY /icefaces4/trunk/icefaces/core/src/main/java/org/icefaces/impl/application/PropagatingNavigationHandler.java
          Repository Revision Date User Message
          ICEsoft Public SVN Repository #47090 Thu Feb 04 11:38:36 MST 2016 ken.fyten ICE-10903 - Fix for NCI errors with Liferay portal.
          Files Changed
          Commit graph MODIFY /icefaces4/branches/icefaces-4.1.1/icefaces/core/src/main/java/org/icefaces/impl/application/PropagatingNavigationHandler.java
          Commit graph MODIFY /icefaces4/branches/icefaces-4.1.1/icefaces/core/src/main/java/org/icefaces/util/EnvUtils.java
          Repository Revision Date User Message
          ICEsoft Public SVN Repository #47092 Thu Feb 04 13:00:22 MST 2016 ken.fyten ICE-10903 - Revert unnecessary change to EnvUtils.java.
          Files Changed
          Commit graph MODIFY /icefaces4/branches/icefaces-4.1.1/icefaces/core/src/main/java/org/icefaces/util/EnvUtils.java
          Hide
          Carmen Cristurean added a comment - - edited

          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

          Show
          Carmen Cristurean added a comment - - edited 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
          Carmen Cristurean made changes -
          Resolution Fixed [ 1 ]
          Status Resolved [ 5 ] Reopened [ 4 ]
          Hide
          Neil Griffin added a comment -

          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

          Show
          Neil Griffin added a comment - 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
          Hide
          Ken Fyten added a comment -

          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

          Show
          Ken Fyten added a comment - 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
          Hide
          Ken Fyten added a comment -

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

          Show
          Ken Fyten added a comment - Possible test configuration issue on our end Neil, we are retesting currently.
          Hide
          Carmen Cristurean added a comment - - edited

          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\ .

          Show
          Carmen Cristurean added a comment - - edited 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 \ .
          Hide
          Mircea Toma added a comment -

          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.

          Show
          Mircea Toma added a comment - 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.
          Show
          Mircea Toma added a comment - 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
          Mircea Toma made changes -
          Status Reopened [ 4 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Hide
          Carmen Cristurean added a comment -

          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.

          Show
          Carmen Cristurean added a comment - 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.
          Ken Fyten made changes -
          Link This issue blocks ICE-10945 [ ICE-10945 ]
          Hide
          Carmen Cristurean added a comment -

          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

          Show
          Carmen Cristurean added a comment - 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
          Ken Fyten made changes -
          Status Resolved [ 5 ] Closed [ 6 ]

            People

            • Assignee:
              Mircea Toma
              Reporter:
              Ken Fyten
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: