Messages posted by: ted.goddard  XML
Profile for ted.goddard -> Messages posted by ted.goddard [693] Go to Page: Previous  1, 2, 3 , ... 45, 46, 47 Next 
Author Message
One easy way is to remove icepush.jar from your application (if you are not using push).
Is the network connection dropping because of network conditions (lost wifi signal, or something), or do the Push updates never occur when you are using PortableRenderer?

PortableRenderer is just an Object reference that persists beyond the PushContext (which is tied to the FacesContext) so using it does not affect anything related to network activity. So, if PortableRenderer is not working under good network conditions, it likely means you are obtaining the PortableRenderer instance from a non-JSF thread.

The use of PortableRenderer does not affect the heartbeat (<noop/>) behaviour, but you must be sure to obtain the PortableRenderer instance from a JSF thread before storing it for use by other threads.
You can detect this at the bean level with WindowScope: http://www.icesoft.org/wiki/display/ice/window+scope
org.icepush.pushIdTimeout configures PushID expiry. This is mostly an implementation detail, but the configuration is made available to solve unforeseen problems (such as PushIDs not being cleaned up as expected).

Is the auction sample working for you?

Are you using PushRenderer.addCurrentSession(groupname)
and PushRenderer.render(groupname) in your bean?
A fix for the id being set on the body has been checked in:


Since manually setting the id did not fix your problem, however, there may be a different root cause. I would recommend including an h:panelGroup just inside the body with a manually set id or try simplifying the page until the problem goes away to try to isolate it. You may also want to contact product.support@icesoft.com for individual help resolving the problem.
We will need to investigate this further. In the meantime, it may help to manually set an ID on the body <h:body id="mybody">. Which version of JSF are you using?
This will require investigation by product.support@icesoft.com since the conflict is with commercial code from Oracle.
We would need to investigate this with a test case and run a full set of regression tests with the Oracle parser included. Whether this is an Oracle parser bug or an ICEfaces bug is not clear, but from the Exception it looks like it should be possible to correct. Please contact product.support@icesoft.com.
This likely requires investigation with a test case, so it may be best to contact product.support@icesoft.com.
I would first try mime-mapping in web.xml:


     <extension>p7m </extension>
     <mime-type> application/x-pkcs7-mime </mime-type> 
A fix is now checked in and is undergoing regression testing; please watch the JIRA for further updates.

I believe this is the other way around -- in ICEfaces 1.8 the JSP
support is actually a custom parser which does turn each tag into a component. In the ICEfaces 1.8 Facelet mode, a custom UIInstruction implementation writes start and end tags.

So, it is possible to use plain HTML in ICEfaces pages but there are cases where JSF components are more efficient.

Are there any IDs in the included pages that might conflict with each other within the c:forEach loop?
ICEfaces does not support client-side state saving. In order to provide automatic Ajax features, the DOM is maintained on the server, and this requires server-side state. In many ways, client-side state saving is not an ideal match for JSF overall due to the stateful nature of the component tree (in the client-side case, this is continually transferred between the browser and the server).
Profile for ted.goddard -> Messages posted by ted.goddard [693] Go to Page: Previous  1, 2, 3 , ... 45, 46, 47 Next 
Go to:   
Powered by JForum 2.1.7ice © JForum Team