Return-Path: Delivered-To: apmail-myfaces-users-archive@www.apache.org Received: (qmail 77545 invoked from network); 18 Mar 2008 12:58:48 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 18 Mar 2008 12:58:48 -0000 Received: (qmail 31979 invoked by uid 500); 18 Mar 2008 12:58:42 -0000 Delivered-To: apmail-myfaces-users-archive@myfaces.apache.org Received: (qmail 31935 invoked by uid 500); 18 Mar 2008 12:58:42 -0000 Mailing-List: contact users-help@myfaces.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "MyFaces Discussion" Delivered-To: mailing list users@myfaces.apache.org Received: (qmail 31924 invoked by uid 99); 18 Mar 2008 12:58:42 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 18 Mar 2008 05:58:42 -0700 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [194.152.182.1] (HELO mgate.ops.co.at) (194.152.182.1) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 18 Mar 2008 12:58:04 +0000 Received: from smtp.ops.co.at (smtp.int.ops.co.at [172.27.0.4]) by mgate.ops.co.at (OPS Mail Gateway - authorized use only - NO UCE/UBE C=AT L=VIE) with ESMTP id 0B9C5AFE3A for ; Tue, 18 Mar 2008 13:58:13 +0100 (CET) Received: by smtp.ops.co.at (Postfix, from userid 65534) id 2E5E16E023F; Tue, 18 Mar 2008 13:58:12 +0100 (CET) Received: from [172.27.1.104] (lints2.int.ops.co.at [172.27.1.104]) by smtp.ops.co.at (Postfix) with ESMTP id 87C786E0234 for ; Tue, 18 Mar 2008 13:58:11 +0100 (CET) Message-ID: <47DFBC63.6060403@chello.at> Date: Tue, 18 Mar 2008 13:58:11 +0100 From: "simon.kitching@chello.at" User-Agent: Thunderbird 2.0.0.0 (X11/20070418) MIME-Version: 1.0 To: MyFaces Discussion Subject: Re: AW: AW: Orchestra beginner question: conversation.flash behaves like request scope References: <001801c888d7$e3dae9a0$0800a8c0@Inspiron6400> <47DF8C9A.2050008@chello.at> <002001c888e2$06a1c2b0$0800a8c0@Inspiron6400> <47DFA0F1.4010204@chello.at> <002401c888f4$e6045320$0800a8c0@Inspiron6400> In-Reply-To: <002401c888f4$e6045320$0800a8c0@Inspiron6400> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on smtp.ops.co.at X-Spam-Level: X-Virus-Checked: Checked by ClamAV on apache.org X-Old-Spam-Status: No, hits=-4.0 required=7.0 tests=AWL,BAYES_00,RATWR10_MESSID, SARE_TOCC_USER,SPG_MG_BUY autolearn=no version=2.64 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: > > scope="conversation.access" > orchestra:conversationName="regUserDirectPlanning,regUserRequestPlanning"> > > > > > Or do I have to define two separate beans in Spring: > > scope="conversation.access" > orchestra:conversationName="regUserDirectPlanning"> > > > > > scope="conversation.access" > orchestra:conversationName="regUserRequestPlanning"> > > > > 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