deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: AW: Custom Context utilities
Date Tue, 03 Apr 2012 16:19:08 GMT
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