Stephan Frai schrieb: > Hi Simon, > > thanks for your help. > After I had given the conversation a name, everything worked fine. > > I`ve got a last question: > May I specify more than one conversationName per bean? > Because I`m using the same bean in different workflows. > > E.g: > > <bean id="timeChainJSF" class="com.playoli.timeperiod.jsf.TimeChainJSF" > scope="conversation.access" > orchestra:conversationName="regUserDirectPlanning,regUserRequestPlanning"> > <property name="beanFactory" ref="timePeriodBeanFactory" /> > <property name="timePeriodValidation" ref="timePeriodValidation"/> > </bean> > > Or do I have to define two separate beans in Spring: > > <bean id="timeChainJSF_1" class="com.playoli.timeperiod.jsf.TimeChainJSF" > scope="conversation.access" > orchestra:conversationName="regUserDirectPlanning"> > <property name="beanFactory" ref="timePeriodBeanFactory" /> > <property name="timePeriodValidation" ref="timePeriodValidation"/> > </bean> > > <bean id="timeChainJSF_2" class="com.playoli.timeperiod.jsf.TimeChainJSF" > scope="conversation.access" > orchestra:conversationName="regUserRequestPlanning"> > <property name="beanFactory" ref="timePeriodBeanFactory" /> > <property name="timePeriodValidation" ref="timePeriodValidation"/> > </bean> > It's good to hear it's working for you now.
You need to use the "two separate bean definitions" approach. That gives your EL expressions the ability to say "I want the instance from conversation X" by referencing a different name. I would suggest names requestPlanningTimeChainJSF directPlanningTimeChainJSF rather than _1 and _2 to reflect this [1]. I can't currently think of another way of doing this. If the EL expression just says "timeChainJSF", and the beandef has multiple conversations associated with it, then which conversation would Orchestra choose? For some other conversation frameworks this is not an issue; they only ever have one active conversation at a time. But Orchestra is trying to avoid that assumption. We think that is more powerful - but it is sometimes a little less convenient. [1] Note that Spring allows a bean definition to specify a "parent" definition to inherit settings from. So you can avoid some duplication here by having one "abstract" definition that both the others reference. Regards, Simon
