That code isn't thread-safe, Gurkan. You've got a race condition there. Why not instantiate the map in-line or in the constructor? The map should be final, too.
On Thu, Mar 26, 2009 at 6:00 PM, Gurkan Erdogdu <[email protected]> wrote: > >>>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. > > Did you check out last code? Actually I have just noticed it and committed :) > > Thanks; > > > > > ________________________________ > From: James Carman <[email protected]> > To: [email protected] > Sent: Thursday, March 26, 2009 11:55:02 PM > Subject: Re: setting conversation at request startup > > 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 >> >> >> > > > >
