You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Fasih <fa...@baypackets.com> on 2006/04/08 01:46:09 UTC

[SCXML]: BUG: Inner States with no InitialState

Hi
With reference to my last mail. I tried to add the rest of the states as child state to the one which does the default error handling(I had missed out the <initialstate>). I get a NullPointerException.
The problem is with:
http://jakarta.apache.org/commons/sandbox/scxml/xref/org/apache/commons/scxml/io/SCXMLDigester.html#955
It checks for a null, and continues using the state. How do I file a BUG?

+Fasih

Re: [SCXML]: BUG: Inner States with no InitialState

Posted by Fasih <fa...@baypackets.com>.
I think that the validation will be quite some task. I started off thinking 
on how to go about it, the first problem is the PayLoad. I can generate 
events, but what payload to use! At least in my case, there is a heavy 
dependency on the payloads of the event. Any suggestions? And yeah, If I do 
manage to get something out, would definitely share it with Commons.

+Fasih

----- Original Message ----- 
From: "Rahul Akolkar" <ra...@gmail.com>
To: "Jakarta Commons Users List" <co...@jakarta.apache.org>
Sent: Saturday, April 08, 2006 1:01 PM
Subject: Re: [SCXML]: BUG: Inner States with no InitialState


On 4/8/06, Fasih <fa...@baypackets.com> wrote:
> Sorry for the typo I did mean <initial>. Though many such errors can be
> caught with DTD, there will be many more that would not be.The most common
> would be typo in event names. I was thinking if we can compile the SCXML
> somehow.
> For validation of events, maybe we could generate a class ConnectionEvent
> extends Event for "connection.xxxx" events
> Restrict the creaion of TriggerEvent to the package, and have a method
> fire() on the generated class.
>
> For model consistency, we can have a ModelValidationFramework, which would
> fire all events that a state can transition into + an error state to see 
> the
> behaviour of the Model. I dont think that would be very difficult. I am
> actually planning to do that for my work coz in my case, my scxml will be
> written by end users. And I want to make sure that they dont make silly
> mistakes that are not caught easily.
>
> Comments?
>
<snip/>

Useful ideas, should be on the medium to long term roadmap for Commons
SCXML. Validation (beyond DTD, schema), path testing, stress testing
in XML based programming models is often not well-supported, and such
"tooling" makes a lot of sense for this project atleast. In fact, we
already have a testing package in the Commons SCXML API, though ATM,
it hardly does anything -- just provides simple command-line test
classes.

I'm quite interested in ideas for ensuring/validating model
consistency. If you come up with something, and are so inclined, you
can always propose contributions back to Commons SCXML. In which case,
there are two things you should be aware of:

 * There are no author tags in source files (Commons SCXML specific
policy). Attribution/credit is via commit messages and the team page
on the website.

 * Larger contributions require filing a CLA [1] with the ASF
secretary (ASF wide policy) before they can be accepted.

-Rahul

[1] http://www.apache.org/licenses/index.html#clas


> +Fasih
> ----- Original Message -----
> From: "Rahul Akolkar" <ra...@gmail.com>
> To: "Jakarta Commons Users List" <co...@jakarta.apache.org>
> Sent: Saturday, April 08, 2006 12:50 AM
> Subject: Re: [SCXML]: BUG: Inner States with no InitialState
>
>
> On 4/7/06, Fasih <fa...@baypackets.com> wrote:
> > Hi
> > With reference to my last mail. I tried to add the rest of the states as
> > child state to the one which does the default error handling(I had 
> > missed
> > out the <initialstate>). I get a NullPointerException.
> > The problem is with:
> > http://jakarta.apache.org/commons/sandbox/scxml/xref/org/apache/commons/scxml/io/SCXMLDigester.html#955
> > It checks for a null, and continues using the state. How do I file a 
> > BUG?
> >
> <snip/>
>
> True, an interesting exercise would be to author many illegal SCXML
> documents (with different anomalies) and ensure that the failures are
> always in the best possible places and with decent error reporting
> (rather than an NPE). In this case, its obvious that after logging the
> error, we shouldn't continue. Probably makes sense to die with a
> ModelException. Not having an <initial> defined (I assume
> <initialstate> is just a typo, given the line number you point to) is
> probably a common authoring faux pas, but thats not the only one.
> Furthermore, many of these can't be caught with a DTD, or even a
> schema.
>
> Please follow the guidelines on the Commons SCXML issue tracking page
> [1] to file a bug for this. If you also want to suggest a patch,
> information about creating patches is here [2] (please attach patches
> to the bugzilla ticket, rather than sending to the mailing lists --
> need to change that text on the website). Thanks.
>
> -Rahul
>
> [1] http://jakarta.apache.org/commons/sandbox/scxml/issue-tracking.html
> [2] http://jakarta.apache.org/commons/patches.html
>
>
> > +Fasih
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Re: [SCXML]: BUG: Inner States with no InitialState

Posted by Rahul Akolkar <ra...@gmail.com>.
On 4/8/06, Fasih <fa...@baypackets.com> wrote:
> Sorry for the typo I did mean <initial>. Though many such errors can be
> caught with DTD, there will be many more that would not be.The most common
> would be typo in event names. I was thinking if we can compile the SCXML
> somehow.
> For validation of events, maybe we could generate a class ConnectionEvent
> extends Event for "connection.xxxx" events
> Restrict the creaion of TriggerEvent to the package, and have a method
> fire() on the generated class.
>
> For model consistency, we can have a ModelValidationFramework, which would
> fire all events that a state can transition into + an error state to see the
> behaviour of the Model. I dont think that would be very difficult. I am
> actually planning to do that for my work coz in my case, my scxml will be
> written by end users. And I want to make sure that they dont make silly
> mistakes that are not caught easily.
>
> Comments?
>
<snip/>

Useful ideas, should be on the medium to long term roadmap for Commons
SCXML. Validation (beyond DTD, schema), path testing, stress testing
in XML based programming models is often not well-supported, and such
"tooling" makes a lot of sense for this project atleast. In fact, we
already have a testing package in the Commons SCXML API, though ATM,
it hardly does anything -- just provides simple command-line test
classes.

I'm quite interested in ideas for ensuring/validating model
consistency. If you come up with something, and are so inclined, you
can always propose contributions back to Commons SCXML. In which case,
there are two things you should be aware of:

 * There are no author tags in source files (Commons SCXML specific
policy). Attribution/credit is via commit messages and the team page
on the website.

 * Larger contributions require filing a CLA [1] with the ASF
secretary (ASF wide policy) before they can be accepted.

-Rahul

[1] http://www.apache.org/licenses/index.html#clas


> +Fasih
> ----- Original Message -----
> From: "Rahul Akolkar" <ra...@gmail.com>
> To: "Jakarta Commons Users List" <co...@jakarta.apache.org>
> Sent: Saturday, April 08, 2006 12:50 AM
> Subject: Re: [SCXML]: BUG: Inner States with no InitialState
>
>
> On 4/7/06, Fasih <fa...@baypackets.com> wrote:
> > Hi
> > With reference to my last mail. I tried to add the rest of the states as
> > child state to the one which does the default error handling(I had missed
> > out the <initialstate>). I get a NullPointerException.
> > The problem is with:
> > http://jakarta.apache.org/commons/sandbox/scxml/xref/org/apache/commons/scxml/io/SCXMLDigester.html#955
> > It checks for a null, and continues using the state. How do I file a BUG?
> >
> <snip/>
>
> True, an interesting exercise would be to author many illegal SCXML
> documents (with different anomalies) and ensure that the failures are
> always in the best possible places and with decent error reporting
> (rather than an NPE). In this case, its obvious that after logging the
> error, we shouldn't continue. Probably makes sense to die with a
> ModelException. Not having an <initial> defined (I assume
> <initialstate> is just a typo, given the line number you point to) is
> probably a common authoring faux pas, but thats not the only one.
> Furthermore, many of these can't be caught with a DTD, or even a
> schema.
>
> Please follow the guidelines on the Commons SCXML issue tracking page
> [1] to file a bug for this. If you also want to suggest a patch,
> information about creating patches is here [2] (please attach patches
> to the bugzilla ticket, rather than sending to the mailing lists --
> need to change that text on the website). Thanks.
>
> -Rahul
>
> [1] http://jakarta.apache.org/commons/sandbox/scxml/issue-tracking.html
> [2] http://jakarta.apache.org/commons/patches.html
>
>
> > +Fasih
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Re: [SCXML]: BUG: Inner States with no InitialState

Posted by Fasih <fa...@baypackets.com>.
Sorry for the typo I did mean <initial>. Though many such errors can be 
caught with DTD, there will be many more that would not be.The most common 
would be typo in event names. I was thinking if we can compile the SCXML 
somehow.
For validation of events, maybe we could generate a class ConnectionEvent 
extends Event for "connection.xxxx" events
Restrict the creaion of TriggerEvent to the package, and have a method 
fire() on the generated class.

For model consistency, we can have a ModelValidationFramework, which would 
fire all events that a state can transition into + an error state to see the 
behaviour of the Model. I dont think that would be very difficult. I am 
actually planning to do that for my work coz in my case, my scxml will be 
written by end users. And I want to make sure that they dont make silly 
mistakes that are not caught easily.

Comments?

+Fasih
----- Original Message ----- 
From: "Rahul Akolkar" <ra...@gmail.com>
To: "Jakarta Commons Users List" <co...@jakarta.apache.org>
Sent: Saturday, April 08, 2006 12:50 AM
Subject: Re: [SCXML]: BUG: Inner States with no InitialState


On 4/7/06, Fasih <fa...@baypackets.com> wrote:
> Hi
> With reference to my last mail. I tried to add the rest of the states as 
> child state to the one which does the default error handling(I had missed 
> out the <initialstate>). I get a NullPointerException.
> The problem is with:
> http://jakarta.apache.org/commons/sandbox/scxml/xref/org/apache/commons/scxml/io/SCXMLDigester.html#955
> It checks for a null, and continues using the state. How do I file a BUG?
>
<snip/>

True, an interesting exercise would be to author many illegal SCXML
documents (with different anomalies) and ensure that the failures are
always in the best possible places and with decent error reporting
(rather than an NPE). In this case, its obvious that after logging the
error, we shouldn't continue. Probably makes sense to die with a
ModelException. Not having an <initial> defined (I assume
<initialstate> is just a typo, given the line number you point to) is
probably a common authoring faux pas, but thats not the only one.
Furthermore, many of these can't be caught with a DTD, or even a
schema.

Please follow the guidelines on the Commons SCXML issue tracking page
[1] to file a bug for this. If you also want to suggest a patch,
information about creating patches is here [2] (please attach patches
to the bugzilla ticket, rather than sending to the mailing lists --
need to change that text on the website). Thanks.

-Rahul

[1] http://jakarta.apache.org/commons/sandbox/scxml/issue-tracking.html
[2] http://jakarta.apache.org/commons/patches.html


> +Fasih
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org





---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Re: [SCXML]: BUG: Inner States with no InitialState

Posted by Rahul Akolkar <ra...@gmail.com>.
On 4/7/06, Fasih <fa...@baypackets.com> wrote:
> Hi
> With reference to my last mail. I tried to add the rest of the states as child state to the one which does the default error handling(I had missed out the <initialstate>). I get a NullPointerException.
> The problem is with:
> http://jakarta.apache.org/commons/sandbox/scxml/xref/org/apache/commons/scxml/io/SCXMLDigester.html#955
> It checks for a null, and continues using the state. How do I file a BUG?
>
<snip/>

True, an interesting exercise would be to author many illegal SCXML
documents (with different anomalies) and ensure that the failures are
always in the best possible places and with decent error reporting
(rather than an NPE). In this case, its obvious that after logging the
error, we shouldn't continue. Probably makes sense to die with a
ModelException. Not having an <initial> defined (I assume
<initialstate> is just a typo, given the line number you point to) is
probably a common authoring faux pas, but thats not the only one.
Furthermore, many of these can't be caught with a DTD, or even a
schema.

Please follow the guidelines on the Commons SCXML issue tracking page
[1] to file a bug for this. If you also want to suggest a patch,
information about creating patches is here [2] (please attach patches
to the bugzilla ticket, rather than sending to the mailing lists --
need to change that text on the website). Thanks.

-Rahul

[1] http://jakarta.apache.org/commons/sandbox/scxml/issue-tracking.html
[2] http://jakarta.apache.org/commons/patches.html


> +Fasih
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Re: [SCXML]: BUG: Inner States with no InitialState

Posted by "Mike Sparr - www.goomzee.com" <mi...@goomzee.com>.
Initialstate is attribute of the <scxml> tag:

<scxml xmlns="http://www.w3.org/2005/07/SCXML" version="1.0"
initialstate="state_welcome">

<state id="state_welcome">
<transition event="menu" cond="${x=y}"></transition>
<transition event="menu" cond="${y=z}"></transition>
<transition event="greet"></transition>
</state>

....

In the above scenario, given "greet" doesn't have any guard conditions, it
will be processed.  I'm no guru on the spec but have learned that like you
stated previously the least demanding "wins".  I also learned that you want
it AFTER your guard conditions so they are considered after all, it would
win if a condition above it were not met even if there were other conditions
below...

....

View the W3C Spec page on SCXML and look at Example 6.  It essentially gives
you the fundamentals in a variety of examples.

Best,


Mike





On 4/7/06 5:46 PM, "Fasih" <fa...@baypackets.com> wrote:

> Hi
> With reference to my last mail. I tried to add the rest of the states as child
> state to the one which does the default error handling(I had missed out the
> <initialstate>). I get a NullPointerException.
> The problem is with:
> http://jakarta.apache.org/commons/sandbox/scxml/xref/org/apache/commons/scxml/
> io/SCXMLDigester.html#955
> It checks for a null, and continues using the state. How do I file a BUG?
> 
> +Fasih



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org