>>So my idea was to store the conversationId in a kind of @RequestScoped bean at start of the ServletRequest, so the ConversationComponent doesn't need >>to get the cid from the FacesContext but instead simply asks this 'ConversationBean'. Hmm the longer I think about it, why don't we simply create the >>Conversation at request startup?
Currently we create it for each request, but as specification said at each JSF request. (see WebBeansPhaseListener) >>My basic idea was: we should move the conversationId detection out of the ConversationComponent, and make it part of the 'integration stuff'. So for >>ServletContainers this may work different than for PortletBridges and also different for freaky things like a standalone Swing application. Currently, idea is that I write the conversation id into the JSF UIView root as hidden component with id "javax_webbeans_ConversationId" at the render response phase if the conversation is long-running. At the next JSF post back, I am using this hidden component value as conversation id to get saved conversation. If the request is not post back, I am looking for the *cid* parameter that is set by the WebBeansJSFFilter for JSF redirects. How could we get the conversation id's from the client in other scenarios other than JSF? Conversation ids must be passed between the client and server. In the JSF scenario, we are getting it from the client via jsf hidden component. We can create a SPI for conversation id management. For JSF we can get it from the UIViewRoot. But for other scenarios, in addition to the conversation id management implementation, it is also necessary to handle context management that we did for JSF in the phase listener. Gurkan ________________________________ From: Mark Struberg <[email protected]> To: [email protected] Sent: Thursday, March 26, 2009 10:26:21 PM Subject: setting conversation at request startup Gurkan, I think I need help :) Currently we set the Converation via the ConversationComponent which gets the conversationId from the FacesContext. The FacesContext is essentially the same thing as we already have with our WebBeansContext. It's 'simply' a ThreadLocal container for session/app/request/page information. So my idea was to store the conversationId in a kind of @RequestScoped bean at start of the ServletRequest, so the ConversationComponent doesn't need to get the cid from the FacesContext but instead simply asks this 'ConversationBean'. Hmm the longer I think about it, why don't we simply create the Conversation at request startup? My basic idea was: we should move the conversationId detection out of the ConversationComponent, and make it part of the 'integration stuff'. So for ServletContainers this may work different than for PortletBridges and also different for freaky things like a standalone Swing application. txs and LieGrue, strub
