IMO it would be better if CDI offered reusable conversations, like we did with Weld, rather than it being an extension. So you can just take advantage of Weld's conversation stuff, or OWB's.
Maybe there is a need to have something before we get this in CDI 1.1? On 3 Apr 2012, at 13:55, Alan D. Cabrera wrote: > That's actually the code I was looking at before I started this thread. This > led me to think, if I need it then I'm pretty sure that other framework > developers would need it as well, my needs being pretty straightforward. > > > Regards, > Alan > > > On Apr 3, 2012, at 3:44 AM, Pete Muir wrote: > >> 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 <pm...@redhat.com> >>>> >>>>> 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 >>>>> >>>>> >>> >> >
