not for JSF. In JSF, the FacesContext behaves different if you run under a Portlet or under a ServletContainer.
But for Wicket, there may be something to be done manually (ServletRequest vs PortletRequest). But I suggest to first concentrate on nacked ServletContainers and full J2EE stacks. I think there is enough work left to do ;) LieGrue, strub --- James Carman <[email protected]> schrieb am Fr, 27.3.2009: > Von: James Carman <[email protected]> > Betreff: Re: setting conversation at request startup > An: [email protected] > Datum: Freitag, 27. März 2009, 0:09 > Would it be necessary (or at least > nice :) to perhaps implement a > portlet-specific implementation of the conversation > management, too? > > Also, would you guys like me to submit some patches to help > out? Is > there anything that you'd feel comfortable letting me > tackle? > > > On Thu, Mar 26, 2009 at 7:04 PM, Mark Struberg <[email protected]> > wrote: > > > > apologise for not checking this in, my girlfriend > pulled me off my chair for watching a movie :) > > I didn't look at the code yet, but I like the idea > with the SPI. Guess this is the most simple solution here. > > > > Wdyt about OWB-88? I think it should be possible to > split the whole JSF part into an own module without breaking > the spec or losing performance. > > > > txs and LieGrue, > > mark > > > > > > --- Gurkan Erdogdu <[email protected]> > schrieb am Do, 26.3.2009: > > > >> Von: Gurkan Erdogdu <[email protected]> > >> Betreff: Re: setting conversation at request > startup > >> An: [email protected] > >> Datum: Donnerstag, 26. März 2009, 22:31 > >> >>>Firstly I have got > >> compile error in the WebBeansFinder class. It > uses > >> *import > >> > org.apache.webbeans.conversation.ConversationManager;* but > >> it > >> seems that >>>you have not committed this > package > >> yet, ConversationManager > >> is still in the jsf package. > >> > >> I have changed the packages. I have just added > the > >> *conversation* package and added > ConversationManager and > >> ConversationImpl into it removing from the jsf > package. > >> > >> Gurkan > >> > >> > >> > >> > >> ________________________________ > >> From: Gurkan Erdogdu <[email protected]> > >> To: [email protected] > >> Sent: Thursday, March 26, 2009 10:43:12 PM > >> Subject: Re: setting conversation at request > startup > >> > >> Hi Mark; > >> > >> Firstly I have got compile error in the > WebBeansFinder > >> class. It uses *import > >> > org.apache.webbeans.conversation.ConversationManager;* but > >> it seems that you have not committed this package > yet, > >> ConversationManager is still in the jsf package. > >> > >> For Conversation stuff, > >> > >> As I said before, specification defines the > conversations > >> at the JSF level. It does not define anything for > other than > >> JSF. Maybe we can extend it to use any technology > other than > >> JSF. I will think about it. > >> > >> 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 > >> > >> > >> > > > > > > > > >
