>>>>> On Thu, 12 Feb 2015 07:29:39 -0600, manfred riem <manfred.riem_at_oracle.com> said:
MR> Hi Zhijun,
MR> I respectively disagree here as you are requesting to bleed an
MR> implementation detail into the API for convenience of the implementation.
MR> Note I do not say your points are not valid, but introduction of a new
MR> method should NEVER be because of an implementation detail forcing this.
MR> So please go ahead and see what would be necessary to prototype this.
Manfred and I talked about this today and he brought me around to his
viewpoint. I prototyped a simpler solution based on Zhijun's idea that
does not require an API change, let's take that portion of the
discussion over to dev_at_javaserverfaces.java.net. Let's use this thread
to state the proposed resolution of the spec issue.
I propose to resolve this issue by adding the following text to the
"Managing Flows" section of FlowHandler:
Because Flow instances are immutable, yet the flow stack is per-user,
implementations must make allowance for flow scoped data (managed
beans declared to be FlowScoped and data stored in the Map returned by
getCurrentFlowScope()) to be fully re-entrant. For example, consider
an application with two flows, A and B, each with a single FlowScoped
bean MyBeanA and MyBeanB, respectively. Entry into flow A causes
MyBeanA to become active. Calling from A into B causes MyBeanB to
become active. Calling back into A causes a new instance of MyBeanA to
become active, rather than reactivating the earlier instance of
MyBeanA.
I'm open to further discussion on this, but if no-one follows up, I'll
consider it closed.
Ed
--
| edward.burns_at_oracle.com | office: +1 407 458 0017
| 17 days til DevNexus 2015
| 27 days til JavaLand 2015
| 37 days til CONFESS 2015