Hi Zhijun,
I respectively disagree here as you are requesting to bleed an
implementation detail into the API for convenience of the implementation.
Note I do not say your points are not valid, but introduction of a new
method should NEVER be because of an implementation detail forcing this.
So please go ahead and see what would be necessary to prototype this.
Kind regards,
Manfred
On 2/11/15, 8:08 PM, zhijun Ren wrote:
> Hi Manfred and Ed,
>
> I don't think this solution is a good one,
>
> 1. FlowCDIContext doesn't maintain status, it is used statically, as
> my understanding, it is a something like utility class;
>
> 2. Cardinality mismatch, your solution need maintain the depth for all
> stacks in Map/Collection, if this is done in FlowCDIContext, it is ugly;
>
> 3. The depth variable should be maintained and calculated in
> FlowHandlerImpl$FlowDeque, where it should belong to; By storing
> here, you only need to take care of the calculation of it, other
> things are done well by current mechanism;
>
> Please consider.
>
> BR,
> Zhijun
>
> On 2/11/15, 22:46, manfred riem wrote:
>> If you don't mind I would like Zhijun to try it.
>>
>> Thanks!
>> Manfred
>>
>> On 2/10/15, 4:35 PM, Edward Burns wrote:
>>>>>>>> On Tue, 10 Feb 2015 15:58:56 -0600, manfred
>>>>>>>> riem<manfred.riem_at_oracle.com> said:
>>> MR> Hi Ed,
>>> MR> Looking at it I think this could be locally solved by making
>>> sure the
>>> MR> FlowCDIContext keeps track of the depth by adding one when
>>> entering a
>>> MR> flow and subtracting one when exiting a flow.
>>>
>>> That's a good idea.
>>>
>>> MR> Note I have not prototyped it but all the call sites to the
>>> MR> FlowScopeMapHelper are in FlowCDIContext.
>>>
>>> If you get some time, please do try and see if that approach will work.
>>> I'd rather not have to add that method.
>>>
>>> Ed
>>>
>