From user-return-22469-apmail-commons-user-archive=commons.apache.org@commons.apache.org Tue Feb 10 05:34:14 2009 Return-Path: Delivered-To: apmail-commons-user-archive@www.apache.org Received: (qmail 20387 invoked from network); 10 Feb 2009 05:34:13 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 10 Feb 2009 05:34:13 -0000 Received: (qmail 14120 invoked by uid 500); 10 Feb 2009 05:33:01 -0000 Delivered-To: apmail-commons-user-archive@commons.apache.org Received: (qmail 14069 invoked by uid 500); 10 Feb 2009 05:33:01 -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 14058 invoked by uid 99); 10 Feb 2009 05:33:01 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Feb 2009 21:33:01 -0800 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 rahul.akolkar@gmail.com designates 209.85.221.17 as permitted sender) Received: from [209.85.221.17] (HELO mail-qy0-f17.google.com) (209.85.221.17) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 10 Feb 2009 05:32:54 +0000 Received: by qyk10 with SMTP id 10so3376087qyk.18 for ; Mon, 09 Feb 2009 21:32:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=eEVVQndnt6NXEdafGh6R1vy6wdhg7WAbCG9yf1HrCvs=; b=YTcrZImds02O1dZHtPGmX3L/WFygFfG3jX8Qs8u/iV8BlJ+A1YEl2yjiQFjSIRH/BB WDxF0tiF6eeLeycaSs325pwToKTFXGUzBYJXgEJfOAQRO7Y7VvOMSQSC9E/QOX4P1ohb HXmVYNfTgy5LcraR2bJHf8Qgq71neleEo7Vko= 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:content-transfer-encoding; b=c3kTbno2RhP/83qdERVE8LgVSK27+7FslACUGbDUmQTUYFUBUyyrycvNpPtFMv/Mr6 1PtgUVYg8Qi8cLPu4EyiGY8SD8juFd+yL/OXVgVGod6bM1Pz20OgrSRdw/BAa1GIfOIR 9ddYbOHbWl5DX5zAUSOYCiJOpJ7UZrGnpoi/k= MIME-Version: 1.0 Received: by 10.229.96.142 with SMTP id h14mr2174978qcn.99.1234243953892; Mon, 09 Feb 2009 21:32:33 -0800 (PST) In-Reply-To: References: Date: Tue, 10 Feb 2009 00:32:33 -0500 Message-ID: Subject: Re: [SCXML] Maximum Length of State Names? From: Rahul Akolkar To: Commons Users List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org On Mon, Feb 9, 2009 at 11:20 AM, Lee, Cheryl - ES/RDR -Gil wrote: > Rahul, > > Thanks for the response. I have some state names that are just over 60 c= haracters in length. So, in 2 similar SCXML files (generated by a script) = that are referenced by a master state machine, I have similar state names t= hat are something like (the actual state names are irrelevant) abcdefghijkl= mnopqrstuvwxyz_abcdefghijklmnopqrstuvwxyz_abcdefg and abcdefghijklmnopqrstu= vwxyz_abcdefghijklmnopqrstuvwxyz_abcdefg2 where the names are really long a= nd only differ by the last character. My master state machine inexplicably= jumps from abcdefghijklmnopqrstuvwxyz_abcdefghijklmnopqrstuvwxyz_abcdefg t= o the transition that is after abcdefghijklmnopqrstuvwxyz_abcdefghijklmnopq= rstuvwxyz_abcdefg2. The problem goes away when I make the first state name= shorter and rename it from abcdefghijklmnopqrstuvwxyz_abcdefghijklmnopqrst= uvwxyz_abcdefg to abcdefghijklmnopqrstuvwxyz_. I can work around this prob= lem by making my state names shorter, but the 60+ characters have tremendou= s meaning in my application, and the SCXML files would actually be less rea= dable with shorter state names. I just thought that if you knew of a limit= on the length of state names, it would help me to tailor my script that ge= nerates the referenced SCXML files. I'll experiment to see if I can put so= mething more tangible together that clearly demonstrates my issue. > Yup, please do. There shouldn't be any such restriction. If you can create a simplest demonstrative test case and attach it to JIRA [1], we can dig into this. -Rahul [1] http://commons.apache.org/scxml/issue-tracking.html > Cheryl > > ________________________________ > From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com] > Sent: Fri 2/6/2009 9:57 PM > To: Commons Users List > Subject: Re: [SCXML] Maximum Length of State Names? > > > On Thu, Feb 5, 2009 at 7:59 PM, Lee, Cheryl - ES/RDR -Gil > wrote: >> Hi, >> >> I'm running into some strange behavior of my state machine, and I had a = sneaking suspicion that some of my state names were too similar and too lon= g (differ only in the last character), and that this was resulting in my st= ate machine taking an unexpected transition. Does anyone know what the act= ual limit is on the length of state names, because there clearly seems to b= e one. I fixed my problem in a test case by shortening some of the names o= f the similarly named states, and the issue went away. I now need to find = all of the cases that my state names are too long. >> > > > Threre isn't any restriction on the length of the event name, but the > names are expected to imply an ontology. There is also some limited > wildcard behavior so specifying event=3D"foo.*" will match foo.bar, > foo.baz, foo.bar.baz and so on. > > If you provide some details (actual event names in your case, or even > better, a complete test document) we should be able to tell if the > above applies. > > -Rahul > > >> Thanks! >> Cheryl >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscribe@commons.apache.org > For additional commands, e-mail: user-help@commons.apache.org > > > ________________________________ > This e-mail and any files transmitted with it may be proprietary and are = intended solely for the use of the individual or entity to whom they are ad= dressed. If you have received this e-mail in error please notify the sender= . > Please note that any views or opinions presented in this e-mail are solel= y those of the author and do not necessarily represent those of ITT Corpora= tion. The recipient should check this e-mail and any attachments for the pr= esence of viruses. ITT accepts no liability for any damage caused by any vi= rus transmitted by this e-mail. > > > --------------------------------------------------------------------- > 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