I like this idea! It'll help me a lot! :) I did see something weird in the code, though. The ConversationManager.getInstance() method blasts the map of conversations every time it's called (it creates a new one). This code is called from multiple places, so it would seem like we're losing conversations.
On Thu, Mar 26, 2009 at 5:50 PM, Gurkan Erdogdu <[email protected]> wrote: > I have added the SPI for the conversation service. It is located in the > "spi/conversation" package. I have also added the default conversation > management that is based on the JSF. > > Default configuration is in the > META-INF/openwebbeans/openwebbeans-default.properties with > > #conversation service > org.apache.webbeans.spi.conversation.ConversationService=org.apache.webbeans.spi.conversation.jsf.JSFConversationServiceImpl > > Now, I think it is easy to add other conversation handling code via > implementing the ConversationService and also context management like > WebBeansPhaseListener. > > WDYT ? > > Gurkan > > > > > ________________________________ > From: Gurkan Erdogdu <[email protected]> > To: [email protected] > Sent: Thursday, March 26, 2009 11:21:28 PM > Subject: Re: setting conversation at request startup > >>>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 > > >
