deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pete Muir <pm...@redhat.com>
Subject Re: Custom Context utilities
Date Tue, 03 Apr 2012 16:26:03 GMT
What Arne proposed seems reasonable to me.

On 3 Apr 2012, at 17:19, Mark Struberg wrote:

> 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 <arne.limburg@openknowledge.de>
>> To: "deltaspike-dev@incubator.apache.org" <deltaspike-dev@incubator.apache.org>
>> 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:pmuir@redhat.com] 
>> Gesendet: Dienstag, 3. April 2012 15:20
>> An: deltaspike-dev@incubator.apache.org; 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 <pmuir@redhat.com>
>>>> To: deltaspike-dev@incubator.apache.org
>>>> 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 <pmuir@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
>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>> 


Mime
View raw message