Messages posted by: ted.goddard  XML
Profile for ted.goddard -> Messages posted by ted.goddard [874] Go to Page: 1, 2, 3  ...  57, 58, 59 Next 
Author Message

The whitepaper link appears to be no longer functional for that version, but the initial implementation is in this JIRA. Essentially, the icefacesID provides the CSRF protection token:

ICEfaces 1.8 already protects against CSRF by a similar mechanism, but if integration specifically with CSRF Guard is desired, some investigation would be required (contact product.support@icesoft.com)

It is possible that adding a hidden form field with the same name that CSRF Guard is using would allow it to update the value, yet preserve it between ajax updates. The difficulty here is that the version of JSF being used may not allow prependId=false.
The values of these cookies are read by ICEfaces and ICEpush JavaScript, so they will not function correctly with the HttpOnly setting; in fact, they are primarily used to communicate between browser windows when local storage is not available.

Are you using portlets? Do you have f:ajax or ace:ajax in the page with render regions?

For a single page with a single user, there is actually no need for push to update separate panels -- JSF by default renders the entire page so should update all components to the current data. Another possibility is that the various beans do not have common values, and this could be debugged with logging.
Which element is intended to be updated? The escape="false" might be causing a problem if there is any complication with the embedded HTML being well-formed. It might help to wrap an h:panelGroup with an ID around the changing element. Otherwise, we would likely need to look at some specific output from debugAB which you could send to product.support@icesoft.com.
Look carefully at the page update from the push: the ICEfaces strategy is to always render the entire page, but only the parts of the page that have changed are sent to the browser. If the page update is larger than expected, this means that something in the page is changing each time, requiring a larger update to be sent.

One approach is to enable org.icefaces.diffConfig to debugAB to dump the two versions of the page to the server log and compare them with a diff command.
Which specific version of ICEfaces are you using and are you using both Push and refresh?

Can you run the application in a browser with a network console (such as Chrome) and take a look at the page updates? Are they larger than expected (such as containing the body tag)?
If the URL is completely hidden, the main page may be within an iframe; is that the case?
ICEmobile functionality is now integrated with ICEFaces 4; some migration steps will be necessary, so please try it out and send us any feedback.
This is true, although ICEfaces 1.8 creates a virtual request/response for push requests, which isn't covered by the spec. ICEfaces 2 replaced this behaviour with push notification causing a standard JSF request and no longer makes use of custom ViewHandler or ExternalContext classes.
As the simplest possible test, I would try adding an h:outputText to the page to see if it shows up, next try with something else simple like ace:pushButton.
If you run the complete showcase.war from the bundle, does the tree still show up empty? Any other components that fail in that case?
ICEfaces 1.8 is much older than Servlet 3, so a good option would be to upgrade to ICEfaces 4.

The ServletEnvironmentRequest helps adapt between Servlet, Portlet, and Asynchronous push lifecycles, so there are complexities outside the Servlet case that lead to this. Another option would be to contact product.support@icesoft.com with an enhancement request.
The URL scheme used by ICEmobile-SX and the updated App BridgeIt is defined in the App metadata so that icemobile: and bridgeit: URLs can launch the App. To change this for iOS would require updating the App on the App store.
A fair bit of work was done in ICEfaces 1.8 to support JSP inclusion compatibility, but this has not been investigated for ICEfaces with the move to JSF 2.0, and it's possible that JSF 2.2 is itself not designed for JSP inclusion. The starting point would be to create a HelloWorld example with JSF 2.2 embedded in a JSP page.

Another alternative would be to use an iframe, would that work in your case?
Profile for ted.goddard -> Messages posted by ted.goddard [874] Go to Page: 1, 2, 3  ...  57, 58, 59 Next 
Go to:   
Powered by JForum 2.1.7ice © JForum Team