Here is how to properly check for a namespaced UIViewRoot and prefix a parameter with the namespace:

UIViewRoot viewRoot = facesContext.getViewRoot();
if (viewRoot instanceof NamingContainer) {
    String namingContainerId = viewRoot.getContainerClientId(facesContext);
    if (namingContainerId != null) {
        paramName = namingContainerId + paramName;
    }
}

Attached for now the changes needed for ICEpush to work with namespaced parameters. Additional changes that ICEfaces might require can be created only when Mojarra will release a build that implements this new (parameter namespacing) feature.

It seems that the name-spaced parameters feature will probably make it only in 2.2.7 release of Mojarra, see https://java.net/jira/browse/JAVASERVERFACES-3184 . Only then we can start testing the fixes we have for ICEfaces/ICEpush.

Ed Burns has closed JAVASERVERFACES-3184 with a fix-version=2.2.7 which has a scheduled release date of July 3, 2014. It would be great if this feature could be incorporated into ICEfaces 4.0 final.

Fully implemented the support for parameter namespacing, both in ICepush and ICEfaces (including delta submit). The namespacing can be enabled by setting com.sun.faces.namespaceParameters context parameter to true.

Tested with Mojarra 2.2.7.

Thanks Mircea!

New failures are seen with certain ace:dataTable test applications. Tomcat 7, all browsers. Icefaces 4 trunk r41494. New issues are present even when the config. param to enable the parameter namespacing is not used.
For further information please see:
http://jira.icesoft.org/browse/ICE-10080?focusedCommentId=53872&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-53872

The new failures are seen in the following test applications:
Row State EL
Input Component Processing
Input Component Processing/ with FAjax
StateMap Size
StateMap Sync
Not an issue with ee-maintenance branch.
Browser error appears:
For input string: "7895466090007243068:-5492966339740380774"
class.java.lang.NumberFormatException
Text input changes to a large number after submission.
Example: "test1" was entered into the UPC header filter. Input was submitted. The return value of the input is correct but the textEntry value changes to number. See screen shots before.PNG, after.PNG
Test application located at:
C:\svn\repo\qa\trunk\Regression-Icefaces4\Sparkle\Nightly\dataTable

The input Component Processing test produces this error when entering test into the first 2 test applications header fields. In the normal header test the input text is changed, in the 2nd app (multi row header) the input field displays correctly but the submit button below the table displays the long number as a value instead of "Submit". See screen shot Multi.PNG. These results were produced on 3 different machines using IF4 code revisions 41494, 41495 and 41497.
For the other applications just general interaction would spawn the error, inputting text or clicking on table rows.
Server errors are also seen
Jun 19, 2014 4:31:56 PM com.sun.faces.lifecycle.ApplyRequestValuesPhase execute
WARNING: For input string: "-4144328025155680052:4219605870235345986"
java.lang.NumberFormatException: For input string: "-4144328025155680052:4219605870235345986"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Integer.parseInt(Integer.java:495)
at java.lang.Integer.parseInt(Integer.java:527)
at org.icefaces.ace.component.datatable.SelectionDeltaState.decodeMultipleSelection(SelectionDeltaState
at org.icefaces.ace.component.datatable.SelectionDeltaState.<init>(SelectionDeltaState.java:53)
at org.icefaces.ace.component.datatable.DataTableDecoder.decodeSelection(DataTableDecoder.java:43)
at org.icefaces.ace.component.datatable.DataTableRenderer.decode(DataTableRenderer.java:61)
at javax.faces.component.UIComponentBase.decode(UIComponentBase.java:831)
at org.icefaces.ace.component.datatable.DataTable.processDecodes(DataTable.java:456)
at javax.faces.component.UIForm.processDecodes(UIForm.java:225)
at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220)....
Jun 19, 2014 4:31:56 PM com.sun.faces.context.AjaxExceptionHandlerImpl handlePartialResponseError
SEVERE: java.lang.NumberFormatException: For input string: "-4144328025155680052:4219605870235345986"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Integer.parseInt(Integer.java:495)
at java.lang.Integer.parseInt(Integer.java:527)
at org.icefaces.ace.component.datatable.SelectionDeltaState.decodeMultipleSelection(SelectionDeltaState.java:114)
at org.icefaces.ace.component.datatable.SelectionDeltaState.<init>(SelectionDeltaState.java:53)
at org.icefaces.ace.component.datatable.DataTableDecoder.decodeSelection(DataTableDecoder.java:43)
at org.icefaces.ace.component.datatable.DataTableRenderer.decode(DataTableRenderer.java:61)
at javax.faces.component.UIComponentBase.decode(UIComponentBase.java:831)...........

Fixed endsWith function (from bridge-support) by making sure that the pattern searched in the string is actually found in it before testing that its position is at the end.
Before the fix the lookupViewStateElement was matching incorrectly an input field rendered by dataTable and updating it with the view state key value.

Re-opened due to regression test failure when in parameter namespacing mode.

Attached PDF file with details of numerous regression test failures while using the parameter-namespacing mode.

Mojarra 2.2.7 should have been used for testing since it implements completely the parameter namespacing feature.

Retest results using Mojarra 2.2.7 with parameter namespacing enabled are quite bad.

Results compared against Icefaces4/trunk rev# 41510 of June 25 , 2014.

ICEfaces4 trunk revision# 41530
Server: tomcat7
Browser: FF3.6, IE7 & Chrome35
JSF: Mojarra 2.2.7
Context-param: "com.sun.faces.namespaceParameters=true"

Sample Test Results:
auction
All tests fail - clocks do not run, can not interact with demo.
Passed during the last run with namespace parameters and mojarra 2.2.6
Passes with no namespace parameter and mojarra 2.2.7

scopes
All tests fail - no updates occur when interacting with the demo
Passes with no namespace parameter and mojarra 2.2.7

elementUpdate
Input Elements Individual (All): testing image "url" and image "alt" fails .
Passes with no namespace parameter and mojarra 2.2.7 or mojarra 2.2.6

basic
All tests fail - show/hide fails
Passed during the last run with namespace parameters and mojarra 2.2.6
Passes with no namespace parameter and mojarra 2.2.7

showcase (FF29)
Most tests fail - can not manually navigate to any demos except for some overview demos
Navigation is ok with no namespace parameter and mojarra 2.2.7.

Modified EnvUtils.getParameterNamespace method to return the container's ID only when the view root is a naming container. This behaviour follows what Mojarra is doing when it decides to run with namespaced parameters.

Still tracking this bug down, but this typo "parametr" seems to be preventing Cloud Push from working on the dev.bridgeit.io deployment:

core/src/main/javascript/application.js

24302 mircea.tom onSend: function(callback) {
41327 mircea.tom onSend(asyncConnection, function(query) {
41327 mircea.tom //the callback parameters: function(addParameter)

24302 mircea.tom callback(function(name, value)

);
24302 mircea.tom });
24302 mircea.tom },

Re-opening to address typo and verify.

Fixed typo and verified successfully commit.

Verified Icefaces 4 trunk r42072 samples and dataTable test applications. All regression tests were run. No issues specific to Context-param: "com.sun.faces.namespaceParameters=true" were found.