Return-Path: Delivered-To: apmail-commons-user-archive@www.apache.org Received: (qmail 86769 invoked from network); 10 Aug 2009 20:54:41 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 10 Aug 2009 20:54:41 -0000 Received: (qmail 78450 invoked by uid 500); 10 Aug 2009 20:54:47 -0000 Delivered-To: apmail-commons-user-archive@commons.apache.org Received: (qmail 78331 invoked by uid 500); 10 Aug 2009 20:54:46 -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 78316 invoked by uid 99); 10 Aug 2009 20:54:45 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Aug 2009 20:54:45 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of Martin.Renaud@nuance.com designates 198.71.73.27 as permitted sender) Received: from [198.71.73.27] (HELO mx4.nuance.com) (198.71.73.27) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Aug 2009 20:54:35 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AosBAFAlgEoKAQS+/2dsb2JhbAAIwnQIjlmCRAiBTAU X-IronPort-AV: E=Sophos;i="4.43,355,1246852800"; d="scan'208";a="127963153" Received: from unknown (HELO bn-exchbh1.nuance.com) ([10.1.4.190]) by mx4.nuance.com with ESMTP; 10 Aug 2009 16:54:13 -0400 Received: from postcard.nuance.com ([10.3.4.214]) by bn-exchbh1.nuance.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 16:54:13 -0400 Received: from MT-EXCH01.nuance.com ([10.3.4.210]) by postcard.nuance.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 16:54:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: SCXML: "external" vs. "internal" events Date: Mon, 10 Aug 2009 16:54:12 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SCXML: "external" vs. "internal" events Thread-Index: AcoXEi/NazCJrRi6Rx6rmOFqheweGgC6CsAw References: From: "Renaud, Martin" To: "Commons Users List" X-OriginalArrivalTime: 10 Aug 2009 20:54:12.0600 (UTC) FILETIME=[B6FD7F80:01CA19FC] X-Virus-Checked: Checked by ClamAV on apache.org Hi Rahul, Again, thanks a lot for your guidance. I now have an abstract = implementation of state machine that provided all the features we were = looking for: * Event triggered by state handlers methods are fired automatically. * Execution of handler methods can be executed asynchronously via an = Executor. * Can save state and resume SM execution on another machine via = getMemento()/setMemento(). * An error is logged when an invalid event occurs. =20 So I'm done with the POC and I will recommend to use SCXML in our next = project. As for the suggested improvement on the AbstractStateMachine.invoke(...) = method, I've created an account on JIRA, but I do not have enough = privilege to create an issue yet (or I might just do not know how). The = only operation available to me is "Save". If you could grant me those = privileges, I will gladly put all the information I can into it. Thanks again, Martin -----Original Message----- From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]=20 Sent: Thursday, August 06, 2009 11:49 PM To: Commons Users List Subject: Re: SCXML: "external" vs. "internal" events On Thu, Aug 6, 2009 at 1:58 PM, Renaud, Martin = wrote: > Thanks Rahul for the answers. > > I did implements an "internal" event queue managed by a sub-class of = AbstractMachine (but a super-class of my actual business sm.). =A0It = works well and I'm happy to see there is demand for it. It is not very = complex to do... at least for a POC! > > I also use the "super state" trick successfully to trap and log = irrelevant events being triggered. It will help catch bug in application = code. > > In the process of doing this, I ran in a little issue, probably = something the could be improved in the next version (I fixed it in my = base sm implementation): the event handler methods invoked dynamically = when entering a new state are required to be defined in the "leaf" = implementation of the sm. It makes sense for "business" state, but it = could be convenient to defined "system" state handlers in super class. = It is the case for me "superstate" and "invalid_transition" state added = to handle invalid transition. Using = "MethodUtils.getAccessibleMethod(...)" do the trick perfectly (are there = is already a dependency on beanutils). Let me know if it is useful to = make that suggestion in a more formal way. > Note that the AbstractStateMachine class is meant to serve a set of simple usecases. As you push the boundaries, you will notice its limitations. For more involved usecases, its best to use the defined formalisms in SCXML (send, custom actions, invoke). Your comment above about class hierarchies makes sense -- a more formal way would be to attach a patch to a ticket in JIRA (patch is optional, but issues with patches usually get looked at quicker :-): http://commons.apache.org/scxml/issue-tracking.html Also note that the dependency on BeanUtils will go away in the next major version of Commons SCXML (so the patch shouldn't depend on BeanUtils). The relevant work has been done in the J6 branch: http://svn.apache.org/repos/asf/commons/proper/scxml/branches/J6/ > Now... I have more questions... > > 1) Arguments to state handlers > In AbstractStateMachine code, I see private variables named SIGNATURE = and PARAMETERS that seems to be there to provide some arguments when = calling the event handler methods. But they are not used actually. Is = there any plan (or way) to enable this features (having some object = being supplied to handlers) ? > The variables are used, it just means the handler methods have no arguments. But since the AbstractStateMachine class supports getting at the SCXMLExecutor directly via getEngine(), it has access to the executor's root context (where any arguments that would otherwise be supplied to the handlers based on the state machine execution can be stored). > 2) Create a sm instance in set the current state. > We would like to be able to "save" the state of a sm and recreate it = later in time, probable on another machine, and continue where we were. = But we do not want to persist the whole thing; just the current state = should suffice. In the spec, I saw the history state serve this purpose = to some extends, but can it be done for all the states without adding = the tag everywhere in the sm definition? > Depending on the usecase, it may be possible to get away with just noting the current state. This topic has been discussed several times on this list, here is one example that is perhaps similar to your question (you can dig into the archives for much more on save/restore and persistence/pooling): http://markmail.org/thread/7rzalbdmbtvhr4kq -Rahul > > That's it for now, thanks again for your support. > > -Martin > > > -----Original Message----- > From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com] > Sent: Thursday, August 06, 2009 12:19 AM > To: Commons Users List > Subject: Re: SCXML: "external" vs. "internal" events > > On Wed, Aug 5, 2009 at 5:41 PM, Renaud, = Martin wrote: >> Hi (again...) >> >> >> >> In the examples/usecases provided on the scxml site, the events are >> fired from outside the state machine. I called them "external" = events. >> >> >> Is it valid to trigger events from inside my state machine sub-class, = in >> a state handler method? =A0As I understand it, those events should be >> queued after any pending events (if any). However, it seems that = those >> "internal" events are not processed. >> > > > Actually, there are well-defined semantics for the phrases external > and internal WRT events when it comes to SCXML. > > I think you're saying events are being triggered via state handlers > (which is Java code) while the existing event is being processed. In > the latest release of Commons SCXML (v0.9), the executor does not > maintain an external event queue. As application code, you'd have to > maintain an event queue and add events from the handlers to said > queue, and trigger these on the executor while the queue has elements. > There is an open ticket to add such a queue to the executor > implementation for the next release (no planned date yet). > > If you want to consider triggering events using SCXML markup, you can > consider using the element. For example, see this test case in > v0.9 (long URL, may get fragmented in email): > > = =A0http://svn.apache.org/repos/asf/commons/proper/scxml/tags/SCXML_0_9/sr= c/test/java/org/apache/commons/scxml/send-02.xml > > > >> >> Side question, if an event if fired but it is not >> relevant/applicable/configured for the machine current state, is = there a >> way to have an exception to be thrown? >> > > > Strictly speaking, this is not an interesting case in state machine > theory (it simply gets ignored as no transitions take place), but I do > agree it may be useful information for certain applications. Theres > atleast a couple of ways to deal with this: > > =A0* Add a wildcard transition at a common ancestor state like so: > > =A0 > =A0 =A0 > =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 > > =A0 =A0 =A0 > > =A0 =A0 > =A0 > > =A0* Register an SCXMLListener and check if any onTransition() = callback > is received when an event is triggered. > > -Rahul > > >> >> >> I can provide config + code to illustrate my point, but I'd like to = be >> sure it suppose to work first. >> >> >> Thanks, >> >> >> Martin >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscribe@commons.apache.org For additional commands, e-mail: user-help@commons.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscribe@commons.apache.org For additional commands, e-mail: user-help@commons.apache.org