Ha! This was the other body of code that I was reading. IIUC, all I need to do is to implement
protected Map<Contextual<?>, Instance<?>> getContextualMap(CreationalContext<?> creationalContext) to reflect the scoping semantics that I need. Am I on the right track? Regards, Alan On Apr 3, 2012, at 6:29 AM, Arne Limburg wrote: > Hi, > how do you think about this as a starting point: > https://github.com/openknowledge/openknowledge-cdi-extensions/blob/master/openknowledge-cdi-scope/src/main/java/de/openknowledge/cdi/scope/AbstractContext.java > > Btw: InstanceHolder seems to be a better name for that class since instance > has another meaning in CDI... > > Regards, > Arne > > -----Ursprüngliche Nachricht----- > Von: Pete Muir [mailto:[email protected]] > Gesendet: Dienstag, 3. April 2012 15:20 > An: [email protected]; Mark Struberg > Betreff: Re: Custom Context utilities > > Given that it's what Alan was asking about, I think it's a good discussion to > have ;-) > > I know you think it's broken, but others don't agree. > > On 3 Apr 2012, at 14:17, Mark Struberg wrote: > >> I'm not sure if the CDI Conversation scope is a good example as it is >> widely considered pretty much broken ;) >> >> >> Maybe we start this discussion from a different perspective: which features >> do you like to have solved in a portable/reusable way? >> >> The 3-line >> public InstanceHolder class { >> Bean<?> ban; >> CreationalContext<?> cc; >> Object instance; >> } >> >> which you store in the underlying storage (e.g. a Map)? >> >> The get(Bean) and get(Bean, CreationalContext) methods? >> >> >> LieGrue, >> strub >> >> >> >> ----- Original Message ----- >>> From: Pete Muir <[email protected]> >>> To: [email protected] >>> Cc: >>> Sent: Tuesday, April 3, 2012 2:57 PM >>> Subject: Re: Custom Context utilities >>> >>> 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 <[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 >>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> >
