In fact there are good things in both the Weld and the OWB base class for all
scopes. And since both those CDI impls do have such a base class, it seems that
there is of course some kind of 'common' bits.
@Pete: my main point was not to bitch the CDI Conversation, but the paragraph
below that:
> 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?
I like to break this up in functionality points which we can discuss. The
question for me is "what functionality should such a base class for Context
implementations contain?".
LieGrue,
strub
----- Original Message -----
> From: Arne Limburg <[email protected]>
> To: "[email protected]"
> <[email protected]>
> Cc:
> Sent: Tuesday, April 3, 2012 3:29 PM
> Subject: AW: Custom Context utilities
>
> 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
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>
