On Thu, 2008-08-28 at 14:24 +0200, Juza Petr wrote: > I found interesting information in log file (at the end of AJAX call): > > 2008-08-28 14:21:34,622 DEBUG: exiting from lifecycle.execute in > RENDER_RESPONSE(6) because getResponseComplete is true from one of the > before listeners > 2008-08-28 14:21:34,622 DEBUG: Clearing access-scoped conversation > assetController after rendering view /assetEdit.jsp > > This means that render phase isn't finished but exited. Isn't it problem > for Orchestra?
Yes, this could possibly be the problem. Orchestra regards a conversation as being "accessed" if a method on some bean in the conversation has been called between calls to AccessScopePhaseListener.beforePhase and AccessScopePhaseListener.afterPhase This of course covers the entire normal render phase, which is when beans are expected to be accessed. Now if things are set up so that: * this ajax phase-listener runs *before* the orchestra one * the ajax phase-listener walks the component tree to generate the custom xml output from *within* its beforePhase method * the ajax phase-listener then calls responseComplete at the end of its beforePhase method then a problem will occur. When a phaselistener calls responseComplete, the actual phase processing is skipped. But all the beforePhase and afterPhase methods of all PhaseListeners are still run. So the conversations will be correctly marked as being "accessed", but during the ajax listener's beforePhase method call. Then AccessScopePhaseListener.beforePhase runs *afterwards*. Orchestra of course expects the accesses to occur during the actual rendering phase - but in this particular ajax framework, "rendering" has effectively been moved earlier in time. Could you please set that breakpoint on the getter method in your bean again, and see whether the beforePhase method of a PhaseListener associated with the ajax library is in the call-stack? You could try renaming file "myfaces-orchestra-core-1.2.jar" to "aaa-myfaces-orchestra-core-1.2.jar". This might cause the jsf environment to process the orchestra faces-config first, and therefore cause its phaselistener to be run before the ajax phaselistener. If this really is shown to be the problem here, I don't think it really qualifies as an orchestra bug; rendering is supposed to happen during the rendering phase, not in the "before phase" processing. Of course even then it would be nice for Orchestra to work around the issue - but it is not immediately obvious how. A custom Lifecycle class could certainly clear the "access" flag at the very start of rendering (without caring about PhaseListener ordering) but that is a pretty intrusive solution. If you can confirm this is the problem, though, I will give the issue some more thought. Regards, Simon
