Actually spec. does not define how to start conversation for non-faces get requests. It says followings:
* The long-running conversation context associated with a request that renders a JSF view is automatically propagated to any faces request (JSF form submission) that originates from that rendered page. * The long-running conversation context associated with a request that results in a JSF redirect (a redirect resulting from a navigation rule or JSF NavigationHandler) is automatically propagated to the resulting non-faces request, and to any other subsequent request to the same URL. This is accomplished via use of a GET request parameter named cid con- taining the unique identifier of the conversation. * The long-running conversation associated with a request may be propagated to any non-faces request via use of a GET request parameter named cid containing the unique identifier of the conversation. In this case, the application must manage this request parameter. Also you can read 6.7.4 and 6.7.5 about conversation context! You could ask at Mojarra mailing list! --Gurkan ________________________________ From: Sven Linstaedt <[email protected]> To: [email protected] Sent: Fri, November 13, 2009 3:51:38 PM Subject: Re: Possible conversation propagation bug in OWB and JSF2 ? Hi Gurkan, in the example the conversation is started during a postback. My evaluation application tries to start the conversation during a non-faces (GET) request using a either a PhaseListener or a custom FaceletHandler. This is due to a requirement, that users may jump directly into an order process without having to do a postback before. I reread the specs for any restrictions of conversation usage in JSF, but as afaik there are not any. Anyhow I have researched into the problem by debugging JSF request handling during faces and non-faces requests. There is a particular point were these two differ: Building the UIViewRoot (ViewDeclarationLanguage.buildView()). During a faces request this is done during RESTORE_VIEW, in non-faces ones during RENDER_RESPONSE. The only interesting fact regarding building the view is the initialState flag, which is set after the view is build, if partial state saving is enabled for this viewId. Because the CID is set *before* RENDER_RESPONSE and before the initialState flag is set, this information is discarded during state saving. The implementation assumes it can rebuild the CID from the FaceletHandler tree. I believe this issue rather fits to the Mojarra mailing list. What do you think? br, Sven 2009/11/12 Gurkan Erdogdu <[email protected]> > Hi Sven; > > Could you look at > https://svn.apache.org/repos/asf/incubator/openwebbeans/trunk/samples/jsf2sample/? > I have just added conversation example. > > >> mvn jetty:run > >>http://localhost:8080/jsf2sample/conversation.jsf > > Thanks; > > --Gurkan > > > > > ________________________________ > From: Sven Linstaedt <[email protected]> > To: [email protected] > Sent: Thu, November 12, 2009 2:55:13 PM > Subject: Possible conversation propagation bug in OWB and JSF2 ? > > Hi, > > premise: I am using Mojarra 2.0.1 and a nightly build of OWB. > > While evaluating the above mentioned frameworks for and upcoming project of > my company I ran into and issue using long runnung conversations, which > will > not get propagated to the next view. > > The problem is after a postback the CID could not be retrieved from the > UIViewRoot attributes (WebBeansPhaseListener:85). A manual check while > debugging confirms this observation. So I turn towards the point, where the > CID is set (WebBeansPhaseListener:174) at the view's root. > > Interestingly this works using JSF 1.x, so I digged a bit (and after that a > lot of) deeper: JSF 2.0 introduced a new mechanism called partial state > saving with the goal to reduce the needed amount of memory for view states > (aka component tree's state) in the session. The idea is quite simple: Much > of the components state's information can be rebuild from the view (or > precisely the Facelet of that view) and just the programmatically changes > state information (and of course user postback state changes) need to be > saved along with the component tree. > > To decide when the the initial state from the view is fully set, all > components have a new flag "initialStateMarked", which is set after the > component tree is build in ViewHandlingStrategy.buildView() during > RENDER_RESPONSE, if there was not any postback before. All changes to the > tree after this point are written to a special map, only containing the > differences from the original view. This delta map is then saved as the > UIViewRoot tree state after the view is rendered in > ViewHandlingStrategy.renderView(). > > So where is the problem? OWB saves the CID before RENDER_RESPONSE (which > sounds correct to me). The initial state flag is set during > RENDER_RESPONSE, > after the CID is set at UIViewRoot attributes. When the component state is > saved, the CID is not noticed, because it was set as part of the initial > state and not the delta state. > > So far I have found one work around: There is an ServletContext init > parameter (javax.faces.FULL_STATE_SAVING_VIEW_IDS), which enables legacy > state saving for particular view IDs. > > The only other solution I can think of currently is marking the > UIViewRoot's > initialState flag before setting the CID in WebBeansPhaseListener. > > Because I am neither an expert for JSF2 nor for JCDI I would like to hear > your opionen about this topic. Do you know of any side effects, if the > initial state is marked before RENDER_RESPONSE? > > > br, Sven > > > > >
