Hi averas, what kind of errors are you getting? What is the runtime environment (server)?

I tried it a while ago with ICEFaces 1.8.2 and Seam 2.2.0 on tomcat 6.0.20 and it worked.

Right now, I'm having problems with ajax push with IE8, with firefox 3.5.5 everything works fine, but with IE it has a strange behavior, the first update (ajax-push) works, but the following ones didn't.

I found in the ICEFaces Jira that last year they have developed a version of auctionMonitor with seam (http://jira.icefaces.org/browse/ICE-1676), but I can't find it.

Can anyone of ICEFaces tell us if that sample is still available and where to find if?

Between, have anyone seen problems with ajax-push (Using RenderManager API) and IE8?

Thanks,
Bruno. 

<h:outputText value="#{bean.value} />
 <ice:form>
    <ice:commandButton action="#{bean.longSubmit()}" value="Long submit" />
 </ice:form>

@Name("bean") @Scope(ScopeType.SESSION)
 public class Bean implements Serializable {
 
 private String value = "";
 
 public void longSubmit() {
 
    SessionRenderer.addCurrentSession("test");
    
    <-- A unit of time consuming work that sets value -->
 
    SessionRenderer.render("test");
 
    <-- Another unit of time consuming work that sets value -->
 
    SessionRenderer.render("test");
 
 }
 
 public String getValue() {
     return value;
 }
 
 }

The latest example of SessionRenderer with Seam would be the open18ice example. It is hosted on google code (Dan Allen Seam In Action) and reference is made to it in Dan's excellent book about Seam.
http://code.google.com/p/seaminaction/source/browse/trunk/#trunk/prototype/projects/open18ice%3Fstate%3Dclosed

It's a pretty simple api, and I would probably not add the bean in application scope though. If you are using Seam to take advantage of their conversation scope/lazy loading of data, then you would probably be creating (and adding beans to the SessionRenderer groups) from a conversation scope. Where you want to trigger the actual rendering could be anywhere, but it's pretty simple.

For every release of ICEfaces, this api is tested with all IE, FF and Safari (sometimes Chrome as well). As a suggestion, you might clear the browser cache if one browser if giving you difficulty.

 

What SessionRenderer does is actually to spin off a new thread (async) of the jsf lifecycle. The RenderHub is responsible for maintaining the queue of "push" threads. If a view (bean that has already been added to the render group) is already in the RenderHub, then it isn't added again.
Hopefully this answers your question. 

No...actually what I am saying is that SessionRender.addCurrentSession will take care of the business for you. If the view is already in the queue/RenderHub, then the framework will take care that it isn't added again (unnecessarily). You can trigger pushes for the same view as often as you want without worrying about efficiency.

As for progressMonitor, there are examples in component-showcase of a determinate as well as indeterminate thread and the component itself assists in "pushing" the updated value to the view. 

Could it be due to the fact that your example is a bean in application scope (so when does it change? Are you always calling an application-scoped bean? With Seam, the application-scoped beans are not synchronized, so not sure if this affects it either. Perhaps you might want to check out the open18ice example? 

You do have the following set in your web.xml, correct?
Code:

   
  <context-param>
         <param-name>com.icesoft.faces.synchronousUpdate</param-name>
         <param-value>false</param-value>
     </context-param>
 

 

For some reason, i thought I read your bean as application-scoped, but now see that it is session-scoped. How about using an @Create method to add your bean and then push it in your method. You might want to trace through at run-time to ensure the bean is added to the render group (specifically the render method of SessionRenderer and ensure that the OnDemandRenderer is not null and the request for render is queued).