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 >>>>>>> >>>>>>> >>>>> >>>> >>> >>
