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