PortableRenderer = PushRenderer.getPortableRenderer() įor the threading part, I used implements Runnable on my class, and for handling multiple threads in a single class, I followed this StackOverflow post: How to deal with multiple threads in one class? My PortableRenderer is declared as PortableRender portableRenderer and in my init() method (called by the class constructor) contains: PushRenderer.addCurrentSession("fullFormGroup") Once the main thread kicks off both execution and polling threads, it terminates and it completes the original HTTP request. I now have three threads in my backing bean- one for executing the long operation, one for polling the status, and one "main" thread for spawning the new threads and returning UI control to the client browser. Multithreading was the missing link, in conjunction with PushRenderer and PortableRenderer (see ). It seems like it would work, but I don't want to spend time hacking together such an inelegant solution when I would hope that there is a more elegant solution built into JSF/ICEfaces.Īm I missing something, or is resorting to ugly hacks the only way to achieve the desired behavior? One possible solution that comes to mind is to have an invisible button somewhere that is automatically "pressed" by the bean when step 1 of the long operation completes, and by clicking it, it calls step 2, and so on and so forth.
ICEFACES COMPONENTS CODE
I have tried using FacesContext.getCurrentInstance().renderResponse() and other functions, such as PushRenderer.render(String ID) to force XmlHttpRequest to initialize early, but no matter what, the appearance of the component does not change until the Java code finishes executing.
However, since the component is only updated at the render response phase, it doesn't show any output until the Java methods have finished executing, and it shows it all changes accumulated at once. The problem is, I have a long file-copy operation to perform, and I would like the the inputText component to show a periodic status update. However, it seems that the change in variable isn't "noticed" by the component until the end of the JSF cycle (which, from my basic understanding, is the render response phase).
In theory, variable value is programmatically modified, and the component sees the change and updates its appearance/properties accordingly. I have an ICEfaces web app which contains a component with a property linked to a backing bean variable.
0 kommentar(er)
