|
Sort Order:
[
Permalink
| « Hide
]
Keith Donald added a comment - 13/Aug/06 10:06 PM
Thanks Chris, your contributions here are welcome and will be reviewed for integration.
I've been working on other projects for a while so haven't looked at this quite yet.
Back on the project now so will contrib soon. Here's the code for this.
It's WRT spring 2.0. At the moment the FlowRequestContextListener acts as a BeanFactoryPostProcessor to register the three contexts. This might be better rolled into the FlowExecutorImpl, that would seem to be the logical place for it. The FlowExecutor could also perform the actions currently performed by the listener, setting the current flow execution context into the context holder and cleaning up the various contexts at the appropriate juncture. Oh, please note that I've not updated to webflow RC4 yet either, so the code might change a little. I don't see the new context introduced in RC4 requiring a spring context, since it's only transient anyhow.
Scheduled for 1.1. Particularly useful in a JSF environment with a Spring DelegatingVariableResolver for lazy-initialized flow-scoped beans.
I tried.
However, I failed to launch a new flow. Environment: spring-webflow-1.1-SNAPSHOT-20070507-85.zip SWF+JSF "index.jsp" <jsp:forward page="dummy.faces?_flowId=PhonebookFlow" /> "PhonebookFlow.xml" <flow ...> <start-state idref="start" /> <action-state id="start"> <bean-action bean="PhonebookFlowAction" method="start" /> </action-state> PhonebookFlowAction refers PhonebookFlowData. PhonebookFlowData is a flow-scoped bean. Attachment file: stacktrace.txt Regarding Suzumis comment;
Ive experienced the same problem - seems to be caused by the fact that the FlowDefinition is built prior to the setting of the flowexecution in the thread local required by the bean factory used in the bean action. postponing the retrieval of the bean until after the FlowDefinition has been created and the flowexecution has been set in the thread local would help - by means of a lazy LocalBeanInvokingAction - that doesnt retrieve the bean from the beanFactory until invocation time.. Hideyuki the problem is that you're creating a singleton that depends on a non-singleton. This is actually a common problem in all of the scoping schemes not just when using Web Flow. While Kai's solution will work the stack trace explains the best solution: 'consider defining a scoped proxy for this bean if you intend to refer to it from a singleton' So you'd see something like this:
<bean id="phoneBookFlowAction" class="...PhoneBookFlowAction"> <property name="phoneBookFlowData" ref="phoneBookFlowData"/> </bean> <bean id="phoneBookFlowData" class="...PhoneBookFlowData" scope="flow"> <aop:scoped-proxy/> </bean> Basically what this does is inject a proxy into the singleton FlowAction and then only look up the target object when the proxy is invoked. It's basically the native Spring way to do Kai's solution and works in all of Spring, not just Spring Web Flow. This issue is not fixed in non-JSF environment.
For more details:
http://forum.springframework.org/showthread.php?t=39294 in reply to Ben:
is one always supposed to wrap non-singleton beans used in flow actions in proxies in order to achieve "laziness" ? Note that the problem i am referring to exists irrespectively of bean dependencies, a flow referencing a single bean with no dependencies will still cause problems as long as the bean is declared with a scope requiring the thread local flowexecution beeing set. Isnt this a flow-initialization problem and not a bean dependency problem? kai:) |
||||||||||||||||||||||||||||||||||||||||||||||||||||
New Feature
Resolved
Major
Add Spring 2.0 custom scopes for Web Flow's scopes
