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

              blocks

              Bug - A problem which impairs or prevents the functions of the product. ICE-10945 showcase-portlet - ACE components not rendered

              • Major - Major loss of function.
              • Closed

                Activity

                Ascending order - Click to sort in descending order
                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
                Permalink
                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 -
                Attachment icefaces4-portlet-4.0.0-SNAPSHOT.zip [ 22024 ]
                Hide
                Permalink
                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
                Permalink
                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
                Permalink
                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
                Permalink
                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
                Permalink
                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
                Permalink
                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
                Permalink
                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
                Permalink
                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
                Permalink
                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
                Permalink
                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
                Permalink
                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
                Permalink
                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
                Permalink
                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
                Permalink
                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
                Permalink
                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.
                Hide
                Permalink
                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

                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
                Permalink
                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
                Permalink
                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: