If you are happy to be tied to a specific CDI implementation, you could use the Weld "bound conversations" - http://docs.jboss.org/weld/reference/1.1.5.Final/en-US/html/contexts.html#d0e5506 - which can be backed by two maps, one representing the "session" and one the "request". Or, you could take a look at how Weld implements conversations for inspiration.
I think we maybe would add a conversation scope like this, that is just bound by maps and api, not tied to the web, in some later version of DeltaSpike. On 2 Apr 2012, at 21:10, Alan D. Cabrera wrote: > Maybe the confusion stems from my lack of experience creating custom > contexts. Let me explain what I'm trying to do. > > I'm trying to manage a state machine, SM, which has been associated with a > particular session scope of a communications link. The current state is a > scope associated w/ that SM. When the SM transitions to a new state the old > state/scope is destroyed and a new one is created. > > I think that it's kind of like a conversation. Is there any example code > that I could look at that supports this kind of scenario? > > > Regards, > Alan > > > > On Apr 2, 2012, at 3:51 AM, Gerhard Petracek wrote: > >> i agree with pete. >> in myfaces codi we have a basic (internal) infrastructure for more advanced >> conversations and a spi for customizing the default behaviour. >> the infrastructure itself just makes sense for "similar" scopes (right now >> we have 4 scopes based on it and they share most of the implementation). >> >> -> it doesn't make sense for scopes which are too different (and the spi >> should be enough to customize the default behaviour of existing scopes). >> it would be nice if you share your requirements, maybe there is an existing >> (custom) scope you can use. >> >> regards, >> gerhard >> >> >> >> 2012/4/2 Pete Muir <[email protected]> >> >>> I'm not quite sure what this would constitute, beyond a trivial base class >>> or a consistent start/stop API. Every context has quite different >>> requirements in my experience, and the hard part is linking the context to >>> the start/stop points, and to whatever backs the context, not the actual >>> context implementation. >>> >>> Do you have some ideas about what utilities you need? >>> >>> On 1 Apr 2012, at 18:05, Alan D. Cabrera wrote: >>> >>>> It sure would be handy if there were a set of utilities available to >>> help framework developers who wish to implement custom Contexts. Maybe I >>> missed something during my perusal or maybe it's not all that tough. >>>> >>>> The context that I need to implement is something of a conversational >>> nature. So I don't think that it's trivial to implement. >>>> >>>> >>>> Regards, >>>> Alan >>> >>> >
