Return-Path: X-Original-To: apmail-commons-user-archive@www.apache.org Delivered-To: apmail-commons-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 69BFF49D2 for ; Fri, 13 May 2011 08:07:39 +0000 (UTC) Received: (qmail 84033 invoked by uid 500); 13 May 2011 08:07:38 -0000 Delivered-To: apmail-commons-user-archive@commons.apache.org Received: (qmail 83385 invoked by uid 500); 13 May 2011 08:07:34 -0000 Mailing-List: contact user-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Users List" Delivered-To: mailing list user@commons.apache.org Received: (qmail 82805 invoked by uid 99); 13 May 2011 08:07:33 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 May 2011 08:07:33 +0000 X-ASF-Spam-Status: No, hits=3.7 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of darac1111@gmail.com designates 74.125.82.171 as permitted sender) Received: from [74.125.82.171] (HELO mail-wy0-f171.google.com) (74.125.82.171) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 May 2011 08:07:26 +0000 Received: by wyb32 with SMTP id 32so2020636wyb.30 for ; Fri, 13 May 2011 01:07:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=fVdq3Vac5k5U69afOLB6RvvhZh906lM6MqPp8RkocV0=; b=tdyFulVXPd9Ac3fL7m8UjrBSYGXCdANSvhM8dYz0OwP1m2KiR185d31YNxzlWJ3gBr NaZRX9nttPtw6J1EaiFtXnLARXpLDWbSR9M/XT2+FXMdL9KbfUdNB8uinuAepuqJOneE 3eMFFsw3ZqQv7Hr/y17sTNiZG63KUJ50v+lrc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=q7snnNMDkGd/C52qA/o56thtXmXcMulFndEQKU1p7CgTXAsXmwmFdXHPsQ178X+MlP cc+ay9Gbg/XZDi7XeLiFnOoBxp8/OHlZASX/Zxpi0qZGN89Du5ycZ+4+CYrrbygiofXu JQ0qpp3QectRan6osOk3lRYHeOixyulCQpS18= MIME-Version: 1.0 Received: by 10.227.167.132 with SMTP id q4mr1136348wby.87.1305274025060; Fri, 13 May 2011 01:07:05 -0700 (PDT) Received: by 10.227.37.163 with HTTP; Fri, 13 May 2011 01:07:04 -0700 (PDT) In-Reply-To: References: Date: Fri, 13 May 2011 10:07:04 +0200 Message-ID: Subject: Re: [scxml] Questions about error events and setting workflow state From: Dario D To: Commons Users List Content-Type: multipart/alternative; boundary=20cf30025c0c99291b04a323ca56 --20cf30025c0c99291b04a323ca56 Content-Type: text/plain; charset=ISO-8859-1 2011/5/12 Rahul Akolkar > On Thu, May 12, 2011 at 6:56 AM, Dario D wrote: > > 2) One requirement for the application is to allow setting an arbitrary > > state in a workflow. For example, if we have the following workflow: > > > > A->B->C->D->E > > > > and the workflow is currently in state D, a user should be able to move > the > > workflow back to state B (or any other state). We were considering to use > > the following way (from the mailing list archives): > > > > public void setState(String state) { > > Set states = getCurrentStatus().getStates(); > > TransitionTarget tt = getStateMachine().getTargets().get(state); > > states.clear(); > > states.add(tt); > > } > > > > Would you recommend doing it this way and how would this affect on any > > context which was previously set? > > > It'd likely be OK with the drawback that it hides these transitions > from the SCXML document (so anyone staring at the document doesn't see > the whole picture). The above doesn't have any effect on the set > context(s). > Thank you for your feedback, as always. In regards to the question and the workflow example, let's suppose that a user has set the current state to B after being in state D. Any local context which may have been created in states C and D will remain associated to those states, until it gets overwritten when the workflow transitions again to C and D, am I right? To continue on the same workflow example, let's supposed that the worklow is in state B. A bug in the workflow has been found at some later stage (states C, D, E) and the user would like to correct this bug before continuing execution of the workflow. Restarting the workflow is not a good idea because actions executed in states A and B are too expensive to be repeated. He corrects this bug and creates a new version of the worfklow model. The application will then call the following method on the existing executor: exec.setStateMachine(newWorkflowModel); This effectively means that the above method would would've been called twice on the executor (when the executor was first created before exec.go(), and after the workflow has been corrected). Is this the right thing to do and again, how would it affect the context which was made during initialization of the worklow and in states A and B? If this is not a good idea, can you suggest any alternatives? --20cf30025c0c99291b04a323ca56--