Re: status and release of commons-scxml-2.0?
Hi Jake,
On 19/04/2019 16.15, Jacob Beard wrote:
Hi Ate,
Thanks for your reply. I think I could help with these issues, and close the
gap for full compliance of the js language model.
That would be great and definitely appreciated.
But that said: I'm still worried if it actually is worth the effort.
Because: who is looking for or (still) waiting for js language
support in commons-scxml?
Community wise, there have been no concrete questions or requests
concerning the js language for many years.
And with the Nashorn engine now deprecated, the current implementation
is besides being incomplete, not sustainable in the long run anyway.
Of course we could consider adding support for GraalVM instead, but is
anyone really asking or waiting for that either?
We currently have pretty solid and SCXML compliant language support with
jexl and groovy, which might be good enough in practice for many, if not
all, of the community.
What I really dislike is further delaying the 2.0 release just because
of the incomplete js language support, and with a unclear idea if it
ever can/will be completed.
Although I personally would still vote +1 to remove js language support,
I also can agree to keep it for a while longer to allow others like you
to chime in and try completing.
But pending that uncertain outcome, I rather proceed with the 2.0
release ASAP anyway, explicitly stating the js language support is not
finished and to be considered alpha or beta.
I was wondering, did you have a timeline in mind for the 2.0 release? I should
start to free up in June/July.
I may be able to spend some cycles the coming month (May) to proceed
with the above idea and work towards a 2.0 release, independent of the
js language support status.
Once we have a 2.0 release out, we can (more) easily roll out newer
minor/patch releases thereafter for improved js language support if and
when we get that incorporated.
Regards,
Ate
Let me know what you think. Thank you,
Jake
On Apr 18, 2019, at 3:46 PM, Ate Douma wrote:
On 18/04/2019 18.00, Jacob Beard wrote:
Hi Ate,
On Apr 18, 2019, at 11:23 AM, Ate Douma wrote:
Only for the javascript language (using Java 8 Nashorn, now deprecated
since Java 11...) there are still 3/188 W3C IRP tests failing.
And those 3 test failures are really, really difficult to fix, because
of limitations/quirks in the Nashorn engine itself.
Could you please provide more information on this? Which tests are failing, and
what are the limitations and quirks of Nashorn that cause this?
Sure.
Regarding 'quirks': see issue SCXML-273 [1] which concerns the problem
that the Nashorn engine by default doesn't fail on referencing a missing
property. Which is tested by W3C IRP test 307.
Regarding limitations: there are two W3C IRP ecma test, 557 and 561,
which make use of XML DOM APIs in a condition, like:
cond="var1.getElementsByTagName('book')[0].getAttribute('title') == 'title1'"
However Nashorn doesn't provide default/native XML DOM support, and
adding that would be (at least from my perspective) quite an effort, if
even properly doable.
That doesn't feel like worth the effort, with little added value/ROI.
[1] https://issues.apache.org/jira/browse/SCXML-273
Thank you,
Jake
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
Re: status and release of commons-scxml-2.0?
On 18/04/2019 18.00, Jacob Beard wrote:
Hi Ate,
On Apr 18, 2019, at 11:23 AM, Ate Douma wrote:
Only for the javascript language (using Java 8 Nashorn, now deprecated
since Java 11...) there are still 3/188 W3C IRP tests failing.
And those 3 test failures are really, really difficult to fix, because
of limitations/quirks in the Nashorn engine itself.
Could you please provide more information on this? Which tests are failing, and
what are the limitations and quirks of Nashorn that cause this?
Sure.
Regarding 'quirks': see issue SCXML-273 [1] which concerns the problem
that the Nashorn engine by default doesn't fail on referencing a missing
property. Which is tested by W3C IRP test 307.
Regarding limitations: there are two W3C IRP ecma test, 557 and 561,
which make use of XML DOM APIs in a condition, like:
cond="var1.getElementsByTagName('book')[0].getAttribute('title') ==
'title1'"
However Nashorn doesn't provide default/native XML DOM support, and
adding that would be (at least from my perspective) quite an effort, if
even properly doable.
That doesn't feel like worth the effort, with little added value/ROI.
[1] https://issues.apache.org/jira/browse/SCXML-273
Thank you,
Jake
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
status and release of commons-scxml-2.0?
Hi developers/community, I've received an out-of-band request about the current status of commons-scxml-2.0 and its release schedule. As there might be more (hopefully at least a few) people interested in this, and I don't like answering out-of-band questions, I'm giving a heads-up here for the whole community. To be absolutely clear upfront: I've dropped the ball on this (again) since my last burst of changes early 2018. I simply didn't, and still don't, have the cycles and priority to work on this beyond maybe minimally answering a few questions now and then. Now, there have been only very few questions in the last several years, and luckily Woonsan (who is a remote colleague of mine in our d2d job) stepped in to help with those as well. So practically, there hasn't been much demand or pressure to wrap-up the work and finish the 2.0 release. And neither from my d2d job (we're still happily using the 2.0-M1 release without problems so far). But technically, the current master branch towards the 2.0 release *is* practically done and ready to be tagged and released. If/when a few remaining cleanup and polishing tasks are completed... The current master branch *is* already fully compliant with the W3C SCXML 1.0 specification, including passing all the W3C (IRP) tests for it. At least, when using the jexl or groovy script languages. And the Common SCXML 2.0 engine IMO is pretty cool and convenient to use, for those who like/need a formalized statemachine engine. Only for the javascript language (using Java 8 Nashorn, now deprecated since Java 11...) there are still 3/188 W3C IRP tests failing. And those 3 test failures are really, really difficult to fix, because of limitations/quirks in the Nashorn engine itself. So that is where I got 'stuck'. I honestly lost interest and desire to try fix this, given that Nashorn now is deprecated in Java 11 anyway, I don't think anyone is actually using/waiting for the javascript language support to begin with, and so I rather just/simply rip out the whole javascript language support and be done with it. And then, there is the remaining work to: a) Fix/remove/replace existing documentation, which is still mostly based upon the last 0.9 release from more than a decade ago. To do this properly is/would be a major effort in itself, as the commons-scxml-2.0 API is really, really different now. b) Fix/configure the site generation itself (I'm actually clueless) c) Check/adjust current checkstyle and other build/release reports to be more in line with the common practices for Apache Commons projects? For task a) I assume I'd have to take first responsibility, possible/hopefully with some help from Woonsan, because 80+% of the code and API changes were made by me, the rest by Woonsan. However I honestly don't have the cycles to do this properly right now. But if it is acceptable to only do the bare minimum, and at least remove the out-of-date examples and just have a basic/minimal 'getting started' page, I could pull that off in a few weeks time. For task b) I assume other devs may be able to help out a bit: I just needs some explanation and clarification how this (now) is supposed to work. Lastly, for task c) I don't know what the current/common policy is or should be: the only thing I realized is that the current reporting configuration is extremely old (10+ years) and might need adjusting. I guess this is also something other Commons devs might be able to explain or even help out with? Looking forward to further input, and hopefully some offered help, because I really would like to wrap this up, sometime soon. Regards, Ate - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: SCXML project
Hi Martin,
I've disabled JDK 8 javadoc doclint which should 'fix' your below problem.
BTW: can you please use properly wrapped/formatted plain text for your email?
Like your previous message, content below is pretty much unreadable ...
Ate
On 2016-01-28 14:32, Martin Gainty wrote:
Hi Atecurrently testing what happens when log4j.properties or log4j.xml is
missing (cured by inserting a working log4j.properties into scxml classpath)
I am currently experiencing this failure:
Javadoc failure with:
Caused by: org.apache.maven.plugin.MojoExecutionException: Error generating
maven-javadoc-plugin:2.10.3:javadoc:Exit code: 1 -
\scxml\src\main\java\org\apache\commons\scxml2\SCInstanceObjectInputStream.java:80: error:
unexpected end tag: *
Here is the code:
/** * Set custom class resolver callback, or null when no longer needed. * * Typically
usage: * * private void readObject(ObjectInputStream in) throws
IOException,ClassNotFoundException { * ClassResolver currentClassResolver = null; * try { *
if (in instanceof SCInstanceObjectInputStream) { * currentClassResolver =
((SCInstanceObjectInputStream)in).setClassResolver(customClassResolver); * } * ... // read
Object(s) * } * finally { * if (in instanceof SCInstanceObjectInputStream) { *
((SCInstanceObjectInputStream)in).setClassResolver(currentClassResolver); * } * } *
} * * * @see
org.apache.commons.scxml2.env.groovy.GroovyContext#readObject(ObjectInputStream) * @param classResolver custom
class resolver */public ClassResolver setClassResolver(ClassResolver classResolver) {
ClassResolver old = this.classResolver;this.classResolver =
classResolver;return old;}
fubars javadoc and fails the build..for now i can comment out the and
inside comments to bypass
Suggestions are welcomethanksMartin
__
Subject: Re: SCXML project
To: user@commons.apache.org
From: a...@douma.nu
Date: Wed, 27 Jan 2016 22:10:50 +0100
On 2016-01-26 22:36, Martin Gainty wrote:
mvn package doesnt package (testcase fails) currently
java.lang.NullPointerException: null at
org.apache.commons.logging.impl.SLF4JLog.isDebugEnabled(SLF4JLog.java:49) at
org.apache.commons.scxml2.env.SimpleContext.setLocal(SimpleContext.java:178) at
org.apache.commons.scxml2.SCXMLExecutionContext.initializeIOProcessors(SCXMLExecutionContext.java:358)
at
org.apache.commons.scxml2.SCXMLExecutionContext.attachInstance(SCXMLExecutionContext.java:397)
at
org.apache.commons.scxml2.SCXMLExecutor.attachInstance(SCXMLExecutor.java:398)
at
org.apache.commons.scxml2.SCXMLTestHelper.testInstanceSerializability(SCXMLTestHelper.java:258)
at
org.apache.commons.scxml2.SCXMLExecutorTest.testSCXMLExecutorTransitions02Sample(SCXMLExecutorTest.java:139)
correct this small bug lurking in
org.apache.commons.scxml2.env.SimpleContext.java
/**
* Assigns a new value to an existing variable or creates a new one.
* The method allows to shaddow a variable of the same name up the
* Context chain.
*
* @param name The variable name
* @param value The variable value
* @see org.apache.commons.scxml2.Context#setLocal(String, Object)
* as someone forgot to initialize log toss a System.out.println
*/
public void setLocal(final String name, final Object value) {
getVars().put(name, value);
try {
if (log.isDebugEnabled()) {
log.debug(name + " = " + String.valueOf(value));
}
}
catch(NullPointerException npe) {
System.out.println("SimpleContext::setLocal log.isDebugEnabled() where log="+log+"
name="+name+" throws NPE");
}
}
*Obrigado Guilherme*
Martín
AFAICT the above NPE only can occur when configuring an invalid/wrong logging
class (like in the pom.xml for the maven-surefire-plugin) and/or through
explicitly set the the Log instance to null in SimpleContext.java.
When using a clean checkout/clone of the current SCXML git repository (master)
this definitely is not the case, and mvn package works just fine.
So possibly you have local modifications, either to the pom.xml logging
configuration or otherwise causing this exception?
Regards, Ate
Date: Mon, 25 Jan 2016 23:42:01 -0200
Subject: Re: SCXML project
From: guilhermecgss...@gmail.com
To: user@commons.apache.org
Ok Folks,
I will evaluate SCXML.
BTW, I found these paper and it sounds interesting:
http://cdn.intechopen.com/pdfs-wm/46457.pdf
It looks like it exports Stateflow to SCXML
MG>will Stateflow support Harel FSM?
MG>Please confirmMG>Obrigado!
On Sun, Jan 24, 2016 at 10:32 AM, Martin Gainty wrote:
+1
Thanks Gary!
Martin Gainty
__
Date: Sat, 23 Jan
Re: SCXML project
On 2016-01-26 22:36, Martin Gainty wrote:
mvn package doesnt package (testcase fails) currently
java.lang.NullPointerException: null at
org.apache.commons.logging.impl.SLF4JLog.isDebugEnabled(SLF4JLog.java:49) at
org.apache.commons.scxml2.env.SimpleContext.setLocal(SimpleContext.java:178) at
org.apache.commons.scxml2.SCXMLExecutionContext.initializeIOProcessors(SCXMLExecutionContext.java:358)
at
org.apache.commons.scxml2.SCXMLExecutionContext.attachInstance(SCXMLExecutionContext.java:397)
at
org.apache.commons.scxml2.SCXMLExecutor.attachInstance(SCXMLExecutor.java:398)
at
org.apache.commons.scxml2.SCXMLTestHelper.testInstanceSerializability(SCXMLTestHelper.java:258)
at
org.apache.commons.scxml2.SCXMLExecutorTest.testSCXMLExecutorTransitions02Sample(SCXMLExecutorTest.java:139)
correct this small bug lurking in
org.apache.commons.scxml2.env.SimpleContext.java
/**
* Assigns a new value to an existing variable or creates a new one.
* The method allows to shaddow a variable of the same name up the
* Context chain.
*
* @param name The variable name
* @param value The variable value
* @see org.apache.commons.scxml2.Context#setLocal(String, Object)
* as someone forgot to initialize log toss a System.out.println
*/
public void setLocal(final String name, final Object value) {
getVars().put(name, value);
try {
if (log.isDebugEnabled()) {
log.debug(name + " = " + String.valueOf(value));
}
}
catch(NullPointerException npe) {
System.out.println("SimpleContext::setLocal log.isDebugEnabled() where log="+log+"
name="+name+" throws NPE");
}
}
*Obrigado Guilherme*
Martín
AFAICT the above NPE only can occur when configuring an invalid/wrong logging
class (like in the pom.xml for the maven-surefire-plugin) and/or through
explicitly set the the Log instance to null in SimpleContext.java.
When using a clean checkout/clone of the current SCXML git repository (master)
this definitely is not the case, and mvn package works just fine.
So possibly you have local modifications, either to the pom.xml logging
configuration or otherwise causing this exception?
Regards, Ate
Date: Mon, 25 Jan 2016 23:42:01 -0200
Subject: Re: SCXML project
From: guilhermecgss...@gmail.com
To: user@commons.apache.org
Ok Folks,
I will evaluate SCXML.
BTW, I found these paper and it sounds interesting:
http://cdn.intechopen.com/pdfs-wm/46457.pdf
It looks like it exports Stateflow to SCXML
MG>will Stateflow support Harel FSM?
MG>Please confirmMG>Obrigado!
On Sun, Jan 24, 2016 at 10:32 AM, Martin Gainty wrote:
+1
Thanks Gary!
Martin Gainty
__
Date: Sat, 23 Jan 2016 14:07:08 -0800
Subject: Re: SCXML project
From: garydgreg...@gmail.com
To: user@commons.apache.org
Guilherme,
I have not seen much activity. We are all volunteers here, if you want
the
project to move forward, feel free to talk on this list, create Jiras,
and
provide patches.
Gary
On Jan 22, 2016 8:58 AM, "Guilherme Silveira" <
guilhermecgss...@gmail.com>
wrote:
Hi Folks
I am new to FSM and new to SCXML.On the other hand, I am expert in
Simulink, expert in Java and expert in model based systems engineering.
I am currently evaluating SCXML and I would like a*honest, non biased
opinion *on the status of SCXML project.
What I would like to assert if this project has a future, the number of
developers, if the SCXML specification will ever reach a stable
statusand so on
So far, I have noticed few integrations with proprietary softwares
Simulink Stateflow does not export to SCXML, neither does IBM Rhapsody.
How difficult would it be to create custom tool for these
integrations? And
most important, is it REALLY possible to implement in Java all the
functionalities of Simulink Stateflow, without any drawback, with a
friendly user experience and a steep learning curve?
ps: I am not from telecom industry
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
Re: [scxml] update and progress?
On 2015-12-04 16:21, R.C. Hoekstra wrote: Hi Ate, thanks for answering. As for the datamodel... Well, I put the stuff in our project which depended on the datamodel on hold. We wanted to apply a datamodel in order to separate the state flow logic and the numbers used in it, but we haven't done that up to now, because I was afraid that the datamodel on scxml commons would become subject of serious changes. So for us it's still very flexible, as we didn't start with that part yet. I have a slight personal preference for at least the xml in the datamodel, but it's not that important. For us the progress of the project is much more important than the choice on which language support will be there and which not. So I can perfectly live with JSON. And if your proposal leads to greater ease of use and faster implementation, that is fantastic. Please do so. The support for java8 is also fine with me. We're doing everything in java 8. So conclusion: your proposal is supported from over here! Thanks Rinke, that is very helpful feedback! I'll come up with a concrete (lazy consensus) proposal on the *dev* list for: - dropping XML/XPath support - adding JSON datamodel support - requiring Java8 and then take it from there with an updated plan. Regards, Ate best regards, Rinke Hi Rinke, On 2015-11-24 12:24, R.C. Hoekstra wrote: Hi Ate, Woonsan, I was wondering if you guys could give us an update on the progress of SCXML, and tell us how it's going. Specifically, I was wondering if you could give us any clue on when Milestone 2 can be expected. I'm looking forward to the new datamodel features with great interest. I don't see much questions and activity on the mailinglist on scxml, but I'd like you to know that we are still very enthousiastic on the scxml project. That is great to hear, and thank you for saying so! Obviously there hasn't been much progress since early this year :( Main reason for this is that the current M1 release has been sufficient for our current use-cases, so far, and we thus right now don't have a real business driver nor concrete budget/time to work on this during working hours, regrettably. That doesn't mean I (and Woonsan) are no longer interested in working on this, but can only do so on our own account outside office hours. And as we've been very busy with lots of other work, you probably can understand that working on Commons SCXML kind of ended up on the back burner. Also there hasn't been much input from the 'community' either... That said, your question tricked me in reviewing again the current state and outstanding issues, for M2 and beyond, and what can/should be done next. And I now realize again that another reason why I 'dropped the ball' since last February is that at that time I reached several technical and frustrating problems in the current functionality, concerning both the Javascript and XPath datamodel support. As you might know, the now final SCXML 1.0 specification at the end dropped the XPath support because there were no concrete implementations, because of lack of interest and too many complications and limitations with XPath to be able to provide a proper implementation. And those same complications and limitations are also causing serious and invasive problems in the (overall) implementation in Commons SCXML. Honestly, I'm fed up with the XML/XPath datamodel as it is hampering and complicating the implementation way too much. Therefore, I want to propose to completely drop XML/XPath datamodel and language support for Commons SCXML 2.0, before moving on with completing and wrapping up the goals for M2. This however is a very radical change, including dropping the support for the Data() and just added Location() functions for the Jexl and Groovy languages. Instead however, I would like to replace this by providing proper JSON datamodel support, not just for Javascript but also the Jexl and Groovy languages. Technically and functionally this will be: - much easier and straightforward to implement with a lot less edge-cases - much easier and practical to use And in addition, for proper Javascript support we should move to Java 8 (Nashorn Javascript engine), and thus drop support for Java 6 and 7. But before doing so, this needs to be discussed and agreed upon by the Commons SCXML community, however small a group that might be nowadays. I hope you and others can comment on this idea and provide feedback if you would be OK, or why not. If for example you or others strongly depend and rely on XML datamodel support, than this might be a no go, unless you are fine with migrating from XML/XPath to JSON instead. If we can make this decision: drop XML/XPath support, add JSON as alterative, and move to Java 8 as minimum, then we can move forward much faster and with a much cleaner and leaner implementation. I'd then be happy and motivated again to continue working towards M2 shortly, and I know Woonsan is willing to pitch in then as wel
Re: [scxml] update and progress?
Hi Rinke, On 2015-11-24 12:24, R.C. Hoekstra wrote: Hi Ate, Woonsan, I was wondering if you guys could give us an update on the progress of SCXML, and tell us how it's going. Specifically, I was wondering if you could give us any clue on when Milestone 2 can be expected. I'm looking forward to the new datamodel features with great interest. I don't see much questions and activity on the mailinglist on scxml, but I'd like you to know that we are still very enthousiastic on the scxml project. That is great to hear, and thank you for saying so! Obviously there hasn't been much progress since early this year :( Main reason for this is that the current M1 release has been sufficient for our current use-cases, so far, and we thus right now don't have a real business driver nor concrete budget/time to work on this during working hours, regrettably. That doesn't mean I (and Woonsan) are no longer interested in working on this, but can only do so on our own account outside office hours. And as we've been very busy with lots of other work, you probably can understand that working on Commons SCXML kind of ended up on the back burner. Also there hasn't been much input from the 'community' either... That said, your question tricked me in reviewing again the current state and outstanding issues, for M2 and beyond, and what can/should be done next. And I now realize again that another reason why I 'dropped the ball' since last February is that at that time I reached several technical and frustrating problems in the current functionality, concerning both the Javascript and XPath datamodel support. As you might know, the now final SCXML 1.0 specification at the end dropped the XPath support because there were no concrete implementations, because of lack of interest and too many complications and limitations with XPath to be able to provide a proper implementation. And those same complications and limitations are also causing serious and invasive problems in the (overall) implementation in Commons SCXML. Honestly, I'm fed up with the XML/XPath datamodel as it is hampering and complicating the implementation way too much. Therefore, I want to propose to completely drop XML/XPath datamodel and language support for Commons SCXML 2.0, before moving on with completing and wrapping up the goals for M2. This however is a very radical change, including dropping the support for the Data() and just added Location() functions for the Jexl and Groovy languages. Instead however, I would like to replace this by providing proper JSON datamodel support, not just for Javascript but also the Jexl and Groovy languages. Technically and functionally this will be: - much easier and straightforward to implement with a lot less edge-cases - much easier and practical to use And in addition, for proper Javascript support we should move to Java 8 (Nashorn Javascript engine), and thus drop support for Java 6 and 7. But before doing so, this needs to be discussed and agreed upon by the Commons SCXML community, however small a group that might be nowadays. I hope you and others can comment on this idea and provide feedback if you would be OK, or why not. If for example you or others strongly depend and rely on XML datamodel support, than this might be a no go, unless you are fine with migrating from XML/XPath to JSON instead. If we can make this decision: drop XML/XPath support, add JSON as alterative, and move to Java 8 as minimum, then we can move forward much faster and with a much cleaner and leaner implementation. I'd then be happy and motivated again to continue working towards M2 shortly, and I know Woonsan is willing to pitch in then as well. That might still need a few months work to complete, but definitely overseeable. Kind regards, Ate best regards, Rinke - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: SCXML and Script and context access
On 2015-08-18 12:27, Sinisa Zec wrote: Dears, We are using Apache SCXML2 for the project which is based on FSM logic. I am trying for some time to achieve the following: 1.Set some variables in (Groovy)context from Java – X set of variables 2.Read those values in from the
Re: [scxml] bug with script in combination of a chain of transitions
Hi Rinke,
I just had time to look at your example, and quickly discovered where the
problem is.
Further comments inline below.
Regards, Ate
On 2015-06-15 22:37, R.C. Hoekstra wrote:
Hi Woonsan, hi others,
At first, sorry for the late reply. I posted the issue in april, but didn't get
a response in the first two weeks. Then I forgot about it (busy with other
issues), and then just saw your reply, about a week ago.
Anyway, I've been thinking hard about the issue, and I think I now understand
what is going on here.
Then again, sorry that my example wasn't so clear, at first. The problem is
we're having very complicated scxml schemes working with several custom
classes, and I tried to bring the example back to the basics, but probably just
missed the key thing.
It basically comes to this, I discovered. Consider this scxml:
The custom ntd:test tag fires a CXR.negative event.
Now the SCXMLListener reports this for the onentry's and onexit's
...
0.000: Human#0 ONEXIT bla
0.000: Human#0 ONEXIT cxr
0.000: Human#0 ONENTRY untreated
0.000: Human#0 ONENTRY cxr
Note that the problem is that the cxr state's onexit is reported first, and
only at the end of the chain the onentry for cxr is reported. The order should
have been this:
onexit bla
onentry cxr
onexit cxr
onentry untreated
This doesn't happen with logs, it only happens with my own custom action.
The custom action does some tests, and on basis of the state the engine is in,
and has been in (and some other stuff) the outcome is positive or negative.
It then sends back a positive or a negative event, via this code:
TriggerEvent[] evts = { new TriggerEvent(stateMachineEvent,
TriggerEvent.SIGNAL_EVENT, payload) };
scxmlExecutorInstance.triggerEvents(evts);
Here is the culprit: you cannot and may not invoke triggerEvents (reentrant)
from the thread executing the statemachine itself.
SCXML, by specification, is strictly sequential in processing (to ensure
deterministic behavior).
What you should do instead is adding your event to the internal event queue of
the statemachine from within your custom action like:
@Override
public void execute(ActionExecutionContext exctx) throws ModelException,
SCXMLExpressionException {
...
TriggerEvent evt = new TriggerEvent(stateMachineEvent,
TriggerEvent.SIGNAL_EVENT, payload);
exctx.getInternalIOProcessor().addEvent(evt);
}
This will queue your event to be processed during (at the end of) the current
external event processing, before control is returned back to the statemachine
invoker.
Alternatively, you also can add the event to the external IO event queue via
scxmlExecutorInstance.addEvent(evt).
That will queue your event to be processed after the current (and possible other
pending) external event processing.
Or you can even use the ActionExecutionContext.getEventDispatcher() and dispatch
your event indirectly. In that case you might want to take a look at the Send
class implementation for example.
HTH, Ate
where stateMachineEvent is either ".positive" or ".negative".
So what happens is this:
1) state machine exits "bla" -> onexit bla is reported by listener
2) state machine enters "cxr", and goes straight to onentry
3) custom action is executed, scxmlExecutorInstance.triggerEvents is called with
"CXR.negative".
4) Still as part of the custom action, the event is caught in the transition tag, and
state machine directed to "untreated"
5) the "cxr" state is exited -> onexit cxr reported by listener
6) "untreated" state entered -> onentry untreated reported by listener
7) Now that the state of the scxmlExecutoerInstance.triggerEvents call is
reached, only now the custom Actions's execute method is returned.
8) only after the execute method of the custom action returned, the onentry block of
"cxr" is finished, and only after that the "onentry cxr" is reported by the
listener.
So, conclusion:
A) does this scenario make sense?
B) would you consider this as a bug? The behavior is at least tricky...
Thanks, Rinke
Hi Rinke,
Did you run with commons-scxml2-2.0-SNAPSHOT?
I've tried to run the following similar to yours on latest revision, but the
result seems
different from what you're seeing:
http://www.w3.org/2005/07/scxml";
version="1.0"
datamodel="jexl"
initial="test1">
I removed the custom action tags and replaced the script tag with simple log
tags.
And I see the following when I tested it with the stanadlone tool [1]:
$ ./scxml.sh test.scxml
http://www.w3.org/2005/07/scxml";
xmlns:cs="http://commons.apache.org/scxml"; version="1.0" initial="test1"
datamodel="jex
Re: [scxml] bug with script in combination of a chain of transitions
Hi Rinke,
I will try to take a look at your issue later (end of) this week.
It would be helpful if you can report against which version you are experiencing
this behavior: current 2.0-SNAPSHOT or earlier milestone 2.0-M1 or 2.0-M0?
Thanks, Ate
On 2015-06-15 22:37, R.C. Hoekstra wrote:
Hi Woonsan, hi others,
At first, sorry for the late reply. I posted the issue in april, but didn't get
a response in the first two weeks. Then I forgot about it (busy with other
issues), and then just saw your reply, about a week ago.
Anyway, I've been thinking hard about the issue, and I think I now understand
what is going on here.
Then again, sorry that my example wasn't so clear, at first. The problem is
we're having very complicated scxml schemes working with several custom
classes, and I tried to bring the example back to the basics, but probably just
missed the key thing.
It basically comes to this, I discovered. Consider this scxml:
The custom ntd:test tag fires a CXR.negative event.
Now the SCXMLListener reports this for the onentry's and onexit's
...
0.000: Human#0 ONEXIT bla
0.000: Human#0 ONEXIT cxr
0.000: Human#0 ONENTRY untreated
0.000: Human#0 ONENTRY cxr
Note that the problem is that the cxr state's onexit is reported first, and
only at the end of the chain the onentry for cxr is reported. The order should
have been this:
onexit bla
onentry cxr
onexit cxr
onentry untreated
This doesn't happen with logs, it only happens with my own custom action.
The custom action does some tests, and on basis of the state the engine is in,
and has been in (and some other stuff) the outcome is positive or negative.
It then sends back a positive or a negative event, via this code:
TriggerEvent[] evts = { new TriggerEvent(stateMachineEvent,
TriggerEvent.SIGNAL_EVENT, payload) };
scxmlExecutorInstance.triggerEvents(evts);
where stateMachineEvent is either ".positive" or ".negative".
So what happens is this:
1) state machine exits "bla" -> onexit bla is reported by listener
2) state machine enters "cxr", and goes straight to onentry
3) custom action is executed, scxmlExecutorInstance.triggerEvents is called with
"CXR.negative".
4) Still as part of the custom action, the event is caught in the transition tag, and
state machine directed to "untreated"
5) the "cxr" state is exited -> onexit cxr reported by listener
6) "untreated" state entered -> onentry untreated reported by listener
7) Now that the state of the scxmlExecutoerInstance.triggerEvents call is
reached, only now the custom Actions's execute method is returned.
8) only after the execute method of the custom action returned, the onentry block of
"cxr" is finished, and only after that the "onentry cxr" is reported by the
listener.
So, conclusion:
A) does this scenario make sense?
B) would you consider this as a bug? The behavior is at least tricky...
Thanks, Rinke
Hi Rinke,
Did you run with commons-scxml2-2.0-SNAPSHOT?
I've tried to run the following similar to yours on latest revision, but the
result seems
different from what you're seeing:
http://www.w3.org/2005/07/scxml";
version="1.0"
datamodel="jexl"
initial="test1">
I removed the custom action tags and replaced the script tag with simple log
tags.
And I see the following when I tested it with the stanadlone tool [1]:
$ ./scxml.sh test.scxml
http://www.w3.org/2005/07/scxml";
xmlns:cs="http://commons.apache.org/scxml"; version="1.0" initial="test1"
datamodel="jexl">
>8 >8
May 05, 2015 11:44:51 PM org.apache.commons.scxml2.env.SimpleSCXMLListener
onEntry
INFO: enter /test1
May 05, 2015 11:44:51 PM org.apache.commons.scxml2.model.Log execute
INFO: null: logging in test1.1
May 05, 2015 11:44:51 PM org.apache.commons.scxml2.env.SimpleSCXMLListener
onEntry
INFO: enter /test1/test1.1
test1.1.positive
May 05, 2015 11:45:16 PM org.apache.commons.scxml2.env.SimpleSCXMLListener
onExit
INFO: exit /test1/test1.1
May 05, 2015 11:45:16 PM org.apache.commons.scxml2.env.SimpleSCXMLListener
onTransition
INFO: transition (event = test1.1.positive, cond = null, from = /test1/test1.1,
to = /test1/test1.2)
May 05, 2015 11:45:16 PM org.apache.commons.scxml2.model.Log execute
INFO: null: logging in test1.2
May 05, 2015 11:45:16 PM org.apache.commons.scxml2.env.SimpleSCXMLListener
onEntry
INFO: enter /test1/test1.2
test1.2.positive
May 05, 2015 11:45:47 PM org.apache.commons.scxml2.env.SimpleSCXMLListener
onExit
INFO: exit /test1/test1.2
May 05, 2015 11:45:47 PM org.apache.commons.scxml2.env.SimpleSCXMLListener
onTransition
INFO: transition (event = test1.2.positive, cond = null, from = /test1/test1.2,
to = /tes
Re: [SCXML] heads-up: Major SCXML 2.0 trunk refactoring incoming - breaking changes and intermediate instability to be expected!
Hi SCXML developers and users, This is a follow-up on the current status of the incoming 'breaking changes'. Good news: the trunk is stable again :) I've just committed the last set of intended changes through SCXML-213 [1], SCXML-221 [2] and SCXML-222 [3]. I invite anyone interested to checkout and update to the latest trunk and try and test it out yourself. But be aware that there *are* important changes. Some of the APIs changed, although it depends on how much you've been extending/customizing Commons SCXML if you'll have to adjust your code base or not. Most significant probably in that regard are the changes to the EventDispatcher interface and the *removal* of the SimpleScheduler, which has been 'collapsed' in the now much more complete SimpleDispatcher class. More invasive probably are the possible changes in the SCXML document you might have to make, specifically if you've been using the Data() xpath builtin function, which was re-implemented and changed on signature (now only taking one instead of two parameters). Furthermore, a new Location() xpath builtin has been added, which you now *must* use instead of the Data() function for location expressions. Finally, one specific behavioral change of the action is important to note (below copying the comment from SCXML-213): The action without a specified delay used to deliver the event through the internal I/O event queue. This however was in violation of the specification (unless target="#_internal" is specified, which wasn't supported yet). This behavior now has been changed to be in compliance with the specification, so such actions will now deliver the event through the external I/O event queue. This is important, because the Commons SCXML executor will NOT automatically process external events itself: you'll have to invoke SCXMLExecutor.triggerEvents() for that manually! If you used such actions without a specified delay, be aware this WILL cause a behavioral change in your SCXML execution!! You either have to now handle such events manually, like described above, OR specify (which now IS supported) to retain the earlier behavior. And as an extra, I've added support for the "null" datamodel AND the SCXML IRP test cases [4]. With these many changes, the current online documentation is really no longer up-to-date anymore. I'll focus on updating the documentation shortly, after I returned from the ApacheCon EU in Budapest next week. Until then, either hold off diving into the 'latest greatest' or else dive into the code and the unit tests to figure out how/what :) Kind regards, Ate p.s. If anyone is at the ApacheCon next week, I'd love to meet you there. Just ping me through email. Or even better: you can 'find me' when/after I've done my Commons SCXML presentation on Monday morning ;) [1] https://issues.apache.org/jira/browse/SCXML-213 [2] https://issues.apache.org/jira/browse/SCXML-221 [3] https://issues.apache.org/jira/browse/SCXML-212 [4] http://www.w3.org/Voice/2013/scxml-irp/ On 2014-10-27 01:35, Ate Douma wrote: Hi SCXML developers and users, This is a heads-up for everyone using the current SCXML 2.0 trunk for their projects. Please checkout issue https://issues.apache.org/jira/browse/SCXML-213 which I just created, which will requires some extensive refactoring and *breaking* changes to the current datamodel and xpath based expressions handling. And this includes SCXML documents using the supported non-xpath languages like Jexl, Ecmascript and Groovy! These changes are needed to 'fix' the current incomplete and incorrect datamodel handling and in particular the usage of the custom Data() function and the action. This issue, and the related subtasks, will take some time to process and complete, and in the mean time the current SCXML 2.0 trunk might become intermediately instable. So please be warned and probably best do NOT update to the incoming changes until the dust has settled... Unless you'd like to hand me some help, with testing, feedback or otherwise, which I'd definitely would appreciate! I'll send a following heads-up to this list once I think the engine is stabilized again and reliable enough to upgrade again. And as indicated, this WILL result in some breaking changes in how you use the Data() function and action. I'll provide a comprehensive explanation and migration instructions once it is clear what and how exactly has or will be changed. Kind regards, Ate - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [SCXML] Plans for making SCXML more dynamic?
Hi Ben, Very interesting use-case: Commons SCXML into space :) I've only briefly looked at the image you shared, but it is difficult for me to comprehend the exact usage or how this is represented in SCXML. If you'd be able to share some example SCXML document, and how parts of that should be(come) dynamically injected/removed, it might become easier to understand what your requirements are. Thanks, Ate On 26-10-14 15:45, Benoît Thiébault wrote: Hi and thank you for your answers It isn't really clear to me under what conditions you are executing the existing state chart. We are developing an open source scientific software called SPIS (for Spacecraft Plasma Interactions Software http://dev.spis.org). As its name implies, it models the physics of space plasmas around in-orbit satellites, but I guess that's off-topic ;-). We use a state chart to represent what we call the "modelling chain" (cf. attached picture), which is a generic definition of the steps to go through for modelling a spacecraft. The software is based on OSGi and is composed of modules (called bundles in OSGi terminology) that are loaded dynamically. Roughly, we can say that each module provides the features necessary to perform one step of the modelling chain: we have a spacecraft geometry modeller, a mesher, an editor for initial and boundary conditions, etc. When the application starts, all bundles are loaded (we don't know the order in which they are loaded, it's the OSGi framework that decides depending on module dependencies). As of today, we have a unique, central state engine that defines the steps of the modelling chain and the modules trigger the transitions when they are done. For now, there is just a single version of the software, but the idea is to be able, in the future, to provide different versions, with different capabilities depending on the modules provided. It is somewhat similar to what you can do with Eclipse distributions (Eclipse is OSGi-based by the way): depending on the modules installed, you have a Java IDE, a C++ IDE or a Fortran IDE (or something completely different). In our case, we could model different physics and modify the modelling chain on the fly depending on the loaded modules. We call that an IME (Integrated Modelling Environment). In that scenario, we would like the modules to inject in the central state chart the steps they are able to provide, not like today where it isn't dynamic: the state chart is defined centrally and the modules cannot modify it. The solution you suggest is indeed interesting and could solve our problem. I was just wondering what was already coded in SCXML API and what needed to be done (either on our side or in the library). Jake's suggestion is also interesting, but in that case I wonder how would the different state diagrams interact with each other. Kind regards, Ben Can't you simply rewrite (extend) the underlying SCXML XML document and then reload/reset the statemachine with the updated document? That should be trivial to do and always have been possible. Or do you need to retain the current (context) state? That might be tricky as the current state is based on and tied to the SCXML model, so if (sub)modules 'come and go' dynamically, you would need to ensure the SCXML state is still valid and representative for the model. Maybe something like the following is an option? a) lock down the statemachine (disallow concurrent access/execution) b) somehow capture/clone the current internal state externally c) update your SCXML document as you need, using plain XML API or Commons SCXML Java API d) reload the SCXML statemachine e) restore the previously captured state (step b) f) unlock the statemachine AFAICS the above should be doable without changes to the current Commons SCXML implementation (and likely even with the 0.9 version), but for step b and e to probably need to hook into (possibly extend) the Commons SCXML Java API. If you have more concrete problems or otherwise think Commons SCXML really need more dynamics support I'd be happy to discuss them further, but you need to be more specific for me to understand your requirements. And of course I'd welcome contributions as well :) Regards, Ate Kind regards, Ben - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [scxml] passing datamodel elements into method call
Hi Rinke, I've been diving into the datamodel handling, the Data() function and supporting Builtin Java class the last several days. I've now come to the conclusion that what you are asking for *should* be supported by Commons SCXML, and actually *is* supported through the SCXML specification. The current implementation of this functionality in Commons SCXML however is very problematic, not just for your use-case but overall, and I've created issue SCXML-213 to address this. I'm working on the SCXML 2.0 Milestone 2 goal and trying to execute (and pass) the SCXML IPR tests, which is pretty much blocked because of this issue. Anyway, once I've solved this, I expect your requirement will be covered automatically as well! Note though that the scope of SCXML-213 is pretty extensive and will take large scale (breaking) changes, for which I also just send out a separate heads-up to the list... This will take a while to complete, so intermediately implementing a custom action to cover your requirements probably is still worthwhile. Kind regards, Ate On 08-10-14 20:54, Ate Douma wrote: On 08-10-14 11:31, R.C. Hoekstra wrote: Hi Rinke, I think you would get a node if you used DataNode function instead: Could you try that? Regards, Woonsan Hi Woonsan, thanks for your answer. But are you sure about that? If I use it like that, I get an "unknown, ambiguous or inaccessible method dataNode" error. Correct, DataNode() is not a function available (registered) within the context of the expression evaluator. I found the dataNode method in Builtin.java. Its javadoc says: "Manifests within location attribute of element, for Commons JEXL and Commons EL based documents." So what I get from it, is that dataNode can only be used to assign something to a dataNode via . That is not what I want. I want to pass a dataNode including subElements to some java object via the cond attribute, so I can write a java method which is able to check conditions with use of the passed dataNode. So: is there a way in which I can pass a dataNode to a java object in the context which is used in a cond attribute? Data obviously doesn't work, as I can see in the Builtin code that it always is parsed to Double or String. Not by the SCXML spec, and neither (directly) through Commons SCXML extensions. However, it should be trivial to add such functionality yourself through a custom Action. Then you can access and use the Builtin#dataNode method and do whatever you like with a data node element. For a quick intro in writing a custom Action (for Commons SCXML 2.0), see for example slides 12,13 of my presentation at the ApacheCon earlier this year: http://events.linuxfoundation.org/sites/events/files/slides/ApacheConUS2014%20-%20Apache%20Commons%20SCXML%202.0.pdf and I suggest looking at the Commons SCXML Var action as simply example. HTH, Ate best regards, Rinke On Thursday, October 2, 2014 3:53 AM, R.C. Hoekstra wrote: Hi list, Hi people @ scxml commons, Can I pass datamodel nodes to a rootContext var, in order to process it in java? like this: , where: * agent is an object of a java class made available to the RootContext, having a check method returning Boolean. I want this check method to evaluate the datamodelNode, in order to return true or false depending on elements. * datamodelNodeRef is a reference to some node in the datamodel. I managed to pass final nodes as string here, like this: , - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
[SCXML] heads-up: Major SCXML 2.0 trunk refactoring incoming - breaking changes and intermediate instability to be expected!
Hi SCXML developers and users, This is a heads-up for everyone using the current SCXML 2.0 trunk for their projects. Please checkout issue https://issues.apache.org/jira/browse/SCXML-213 which I just created, which will requires some extensive refactoring and *breaking* changes to the current datamodel and xpath based expressions handling. And this includes SCXML documents using the supported non-xpath languages like Jexl, Ecmascript and Groovy! These changes are needed to 'fix' the current incomplete and incorrect datamodel handling and in particular the usage of the custom Data() function and the action. This issue, and the related subtasks, will take some time to process and complete, and in the mean time the current SCXML 2.0 trunk might become intermediately instable. So please be warned and probably best do NOT update to the incoming changes until the dust has settled... Unless you'd like to hand me some help, with testing, feedback or otherwise, which I'd definitely would appreciate! I'll send a following heads-up to this list once I think the engine is stabilized again and reliable enough to upgrade again. And as indicated, this WILL result in some breaking changes in how you use the Data() function and action. I'll provide a comprehensive explanation and migration instructions once it is clear what and how exactly has or will be changed. Kind regards, Ate - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [SCXML] Plans for making SCXML more dynamic?
On 25-10-14 09:22, Benoît Thiébault wrote: Hi everyone, I am very pleased to learn that SCXML is back online and that new evolutions are coming with version 2.0. Congrats and good luck to the development team! I already use SCXML 0.9 in one of my applications and one feature I was missing was a more dynamic state engine. My application is OSGi-based and thus very dynamic: modules come and go at runtime. What I wanted to do was to be able to modify the state diagram at runtime: when a new bundle is loaded, it injects its own state chart as a sub-set of the existing state chart. If I understood SCXML correctly, this was not really possible with 0.9. Is it planned for future versions? It isn't really clear to me under what conditions you are executing the existing state chart. Can't you simply rewrite (extend) the underlying SCXML XML document and then reload/reset the statemachine with the updated document? That should be trivial to do and always have been possible. Or do you need to retain the current (context) state? That might be tricky as the current state is based on and tied to the SCXML model, so if (sub)modules 'come and go' dynamically, you would need to ensure the SCXML state is still valid and representative for the model. Maybe something like the following is an option? a) lock down the statemachine (disallow concurrent access/execution) b) somehow capture/clone the current internal state externally c) update your SCXML document as you need, using plain XML API or Commons SCXML Java API d) reload the SCXML statemachine e) restore the previously captured state (step b) f) unlock the statemachine AFAICS the above should be doable without changes to the current Commons SCXML implementation (and likely even with the 0.9 version), but for step b and e to probably need to hook into (possibly extend) the Commons SCXML Java API. If you have more concrete problems or otherwise think Commons SCXML really need more dynamics support I'd be happy to discuss them further, but you need to be more specific for me to understand your requirements. And of course I'd welcome contributions as well :) Regards, Ate Kind regards, Ben - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
[SCXML] Heads-up for Commons SCXML 2.0-SNAPSHOT users: action updated with breaking changes
Hi Commons SCXML users of the latest 2.0-SNAPSHOT (trunk), Be warned that if you update to the latest committed state in trunk, you likely will have to update your existing SCXML documents when using the action. The action attributes now have been aligned with the latest SCXML specification, see: http://www.w3.org/TR/2014/WD-scxml-20140529/#send This required some breaking changes in naming and handling of some of these attributes. Please review https://issues.apache.org/jira/browse/SCXML-210 before doing a next svn up... (you have been warned) Regards, Ate - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [scxml] passing datamodel elements into method call
On 08-10-14 11:31, R.C. Hoekstra wrote: Hi Rinke, I think you would get a node if you used DataNode function instead: Could you try that? Regards, Woonsan Hi Woonsan, thanks for your answer. But are you sure about that? If I use it like that, I get an "unknown, ambiguous or inaccessible method dataNode" error. Correct, DataNode() is not a function available (registered) within the context of the expression evaluator. I found the dataNode method in Builtin.java. Its javadoc says: "Manifests within location attribute of element, for Commons JEXL and Commons EL based documents." So what I get from it, is that dataNode can only be used to assign something to a dataNode via . That is not what I want. I want to pass a dataNode including subElements to some java object via the cond attribute, so I can write a java method which is able to check conditions with use of the passed dataNode. So: is there a way in which I can pass a dataNode to a java object in the context which is used in a cond attribute? Data obviously doesn't work, as I can see in the Builtin code that it always is parsed to Double or String. Not by the SCXML spec, and neither (directly) through Commons SCXML extensions. However, it should be trivial to add such functionality yourself through a custom Action. Then you can access and use the Builtin#dataNode method and do whatever you like with a data node element. For a quick intro in writing a custom Action (for Commons SCXML 2.0), see for example slides 12,13 of my presentation at the ApacheCon earlier this year: http://events.linuxfoundation.org/sites/events/files/slides/ApacheConUS2014%20-%20Apache%20Commons%20SCXML%202.0.pdf and I suggest looking at the Commons SCXML Var action as simply example. HTH, Ate best regards, Rinke On Thursday, October 2, 2014 3:53 AM, R.C. Hoekstra wrote: Hi list, Hi people @ scxml commons, Can I pass datamodel nodes to a rootContext var, in order to process it in java? like this: , where: * agent is an object of a java class made available to the RootContext, having a check method returning Boolean. I want this check method to evaluate the datamodelNode, in order to return true or false depending on elements. * datamodelNodeRef is a reference to some node in the datamodel. I managed to pass final nodes as string here, like this: , - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [SCXML] onentry executable content parallel to further transitions
On 11-09-14 11:30, Johannes Wienke wrote:
Hi,
On 09/09/2014 04:28 PM, Ate Douma wrote:
On 08-09-14 18:59, Johannes Wienke wrote:
On 09/07/2014 10:31 PM, Ate Douma wrote:
Actually, Commons SCXML already uses an event queue (one for internal
events and one for external events).
It is however the responsibility of separate client threads to only use
the executor #addEvent methods and only use a single client thread for
actual execution and event triggering on the state machine.
The bug you encountered was in the Commons SCXML *internal* delivery of
events which likewise (now) should use #addEvent but still used the
#triggerEvent method instead. This should now be fixed.
Ok, assuming I am always using addEvents to fill the event queue, what
is the correct pattern for a worker thread that then calls
triggerEvents()? As far as I can tell from the implementation, this
method returns immediately in case the queue is currently empty. Hence,
implementing something like
while (true) {
executor.triggerEvents();
}
should result in a loop wasting one CPU in case no external events need
to be processed? This sounds wrong to me.
I think that is typically what you'll need to do, or else add some
'eventAdded' notification and coordination yourself (see below).
Wouldn't it be much nicer from a user perspective if the executor could
offer something like waitForNextEvents() or
waitUntilEventsInExternalQueue()? Depending on the use case, this is
much easier to implement internally than externally.
Yes, that might be possible to add.
But note that the current implementation isn't 'done' yet and several aspects of
the current specification with regards to the event IO processor [1] aren't
completely implemented yet.
That functionally was initially on my plan for milestone 3 in the roadmap [2],
but I already discovered I need some of this earlier on, and I've already
started on some further internal refactoring and enhancements in this area.
But even when completed, such 'automatic' event coordination and execution still
should remain an optional feature only to allow for other solutions where this
coordination better be done within custom and domain specific client code.
My goal anyway is to first get the event IO processing in place as required by
the specification.
But of course I'm also open for contributions and development support in
general :)
[1] http://www.w3.org/TR/scxml/#eventioprocessors
[2]
http://commons.apache.org/proper/commons-scxml/roadmap.html#Milestone_3:_External_communications_support
Moreover, since SimpleScheduler now uses addEvent, too, I cannot even
know all events that enter the state machine, or am I wrong? So I am
doomed to implement a busy waiting loop.
Yes, in the current implementation you'll have to coordinate this yourself.
It should be trivial though to extend the SCXMLExecutor for your purpose to get
'notified' about such #addEvent invocations.
The initiating thread creating/owning the executor/engine instance
likely also should be responsible for managing the statemachine
execution: instantiating and then starting with go(), continuing with
triggerEvents(), and if needed resetting through reset().
Other threads (as well as the 'owner' thread) can/should only add events
to the queue through addEvent(Event), including threads dispatched from
the engine itself.
Only a single owner thread should 'trigger' subsequent engine processing.
You can use executor.hasPendingEvents() to prevent the overhead of a
trivial amount of CPU cycles, but executor.triggerEvents() with an empty
queue will only impose a minimal overhead anyway.
But if I know that there are currently no pending events, then I can't
do anything else then polling in a busy loop. Either I have to do this
quite often and just increase CPU load or with a larger sleep statement
I will add an unwanted delay in processing.
Maybe you can try my suggestion above: extending SCXMLExecutor probably will
allow for a trivial intermediate solution for this.
Because only the 'owner' thread does (and may do) the actual execution
of the engine, you're guaranteeing, and protecting (yourself!), no
concurrent statemachine processing will happen. The (current) executor
intendedly does NOT enforce this (as you noticed) with synchronization
blocks or otherwise.
Ok, got it. Could you please fix up the respective FAQ entry that is at
least confusing in that respect:
https://commons.apache.org/proper/commons-scxml/faq.html#many-threads
Done, thanks for pointing this out.
It remains that your owner thread will have to use some timer based
triggering of the executor, but that is typical when dealing with
multiple thread coordination/synchronization. Or else you could consider
extending/intercepting the executor to 'notify' your owner thread when
new events are added to the ext
Re: [SCXML] onentry executable content parallel to further transitions
On 09-09-14 11:20, Johannes Wienke wrote:
Hi,
On 09/08/2014 10:07 PM, Martin Gainty wrote:
StringTokenizer st = new StringTokenizer(event);
int tkns = st.countTokens();
TriggerEvent[] evts = new TriggerEvent[tkns];
for (int i = 0; i < tkns; i++) {
executor.triggerEvents();
But then I have to implement a custom logic to restart that loop once
new events arrive after it finished once. Moreover, this doesn't look
thread-safe.
Hi Johannes,
Wrong list or did you intend to raise a question about the above?
The context isn't clear to me and the code example confusing and not
complete/correct either.
Ate
Cheers,
Johannes
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
Re: [SCXML] onentry executable content parallel to further transitions
On 08-09-14 18:59, Johannes Wienke wrote:
Hi,
thanks for the feedback work on this!
On 09/07/2014 10:31 PM, Ate Douma wrote:
Actually, Commons SCXML already uses an event queue (one for internal
events and one for external events).
It is however the responsibility of separate client threads to only use
the executor #addEvent methods and only use a single client thread for
actual execution and event triggering on the state machine.
The bug you encountered was in the Commons SCXML *internal* delivery of
events which likewise (now) should use #addEvent but still used the
#triggerEvent method instead. This should now be fixed.
Ok, assuming I am always using addEvents to fill the event queue, what
is the correct pattern for a worker thread that then calls
triggerEvents()? As far as I can tell from the implementation, this
method returns immediately in case the queue is currently empty. Hence,
implementing something like
while (true) {
executor.triggerEvents();
}
should result in a loop wasting one CPU in case no external events need
to be processed? This sounds wrong to me.
I think that is typically what you'll need to do, or else add some 'eventAdded'
notification and coordination yourself (see below).
The initiating thread creating/owning the executor/engine instance likely also
should be responsible for managing the statemachine execution: instantiating and
then starting with go(), continuing with triggerEvents(), and if needed
resetting through reset().
Other threads (as well as the 'owner' thread) can/should only add events to the
queue through addEvent(Event), including threads dispatched from the engine itself.
Only a single owner thread should 'trigger' subsequent engine processing.
You can use executor.hasPendingEvents() to prevent the overhead of a trivial
amount of CPU cycles, but executor.triggerEvents() with an empty queue will only
impose a minimal overhead anyway.
Because only the 'owner' thread does (and may do) the actual execution of the
engine, you're guaranteeing, and protecting (yourself!), no concurrent
statemachine processing will happen. The (current) executor intendedly does NOT
enforce this (as you noticed) with synchronization blocks or otherwise.
It remains that your owner thread will have to use some timer based triggering
of the executor, but that is typical when dealing with multiple thread
coordination/synchronization. Or else you could consider extending/intercepting
the executor to 'notify' your owner thread when new events are added to the
external queue.
But with that you'll enter a domain specific implementation, not easily
generalizable in Commons SCXML (although I'm happy to review patches ;) ).
Regards, Ate
Cheers,
Johannes
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
Re: SCXML: context thinks it is in no state at all in onentry of non atomic states.
On 02-09-14 23:23, R.C. Hoekstra wrote: Hi all at scxml. In my project I found some behavior which I regarded as unexpected, but maybe I'm overlooking something. In non-atomic states action execution the engine reports to be in no state at all. I made a test Action class which only does one thing: it prints the result of SCXMLExecutor.getStatus().getAllStates() in a listing to StdOut. Consider the following simple scxml file: This shows the following output: entering entry exiting entry my prints 1 state: "1" entering 1 Placing the onentry in an atomic substate like this: shows the following output: entering entry exiting entry entering 1 my prints 2 states: 1 and 1.1 entering 1.1 However, placing the onentry in the parent of that atomic substate like this: gives a result which I hadn't expected: entering entry exiting entry my prints 0 states entering 1 entering 1.1 Here, the action reports that the engine is in NO STATE AT ALL. I can see that the action is always executed before the listener reports it's onentry (of which I'm not sure if it's weird or not), but nevertheless it always reports correctly the states it belongs to. Except when the action is executed on a non-atomic state -> then it believes to be in 0 states. This looks to me like inconsistent, and thus a bug, or am I overlooking some logic? Hi Rinke, This indeed is a bug and the result of how Commons SCXML keeps track of active atomic states only, deriving the set of all states from them dynamically. Clearly in use-cases like yours above this won't be consistent until these active atomic states actually have been entered. I've to think of a proper solution how best to fix this: we might have to track both the active and the all states sets in the Status object now. Which of course will add to its footprint. If you can create a JIRA issue for it, I'll pick it up from there. Regards, Ate Test classes are available at request. best regards, Rinke - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [SCXML] onentry executable content parallel to further transitions
On 02-09-14 12:58, Johannes Wienke wrote: Hi, On 08/29/2014 12:39 PM, Johannes Wienke wrote: we are currently evaluating commons scxml in the trunk version for our purposes. On thing that confused us is the fact that transitions from a state can already occur while that state's onentry executable content is still processing. Hence, we end up with more parallelism than expected. Is this the intended behavior? From the SCXML specification I actually cannot find anything that either allows or prevents this interpretation. So I am also curious how this behavior is justified wrt. to specs. Following up on this: We have found a statement in the SCXML specification that disallows the current behavior. In section 4.10 the specification states: "Note that SCXML treats the executable content triggered by a transition as a single blocking operation and that no events are processed until all the executable content has completed. For example, when taking a transition into state S, the SCXML processor will not process any events or take any transitions until all handlers in S have finished." This is definitely not the case right now when using multiple threads to trigger events. Hi Johannes, Please see my comments and fixes for SCXML-206 and SCXML-207. The problems you were seeing were caused by erroneous and incorrect (internal!) concurrent execution of the same state machine instance, which as you correctly stated above is not allowed. From a design point of view: why do the client threads that trigger events directly process the whole event transition logic instead of using an internal event queue and a processing thread as proposed by the SCXML specification? Actually, Commons SCXML already uses an event queue (one for internal events and one for external events). It is however the responsibility of separate client threads to only use the executor #addEvent methods and only use a single client thread for actual execution and event triggering on the state machine. The bug you encountered was in the Commons SCXML *internal* delivery of events which likewise (now) should use #addEvent but still used the #triggerEvent method instead. This should now be fixed. Regards, Ate Cheers, Johannes - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [SCXML] onentry executable content parallel to further transitions
On 29-08-14 12:39, Johannes Wienke wrote: Hi, we are currently evaluating commons scxml in the trunk version for our purposes. On thing that confused us is the fact that transitions from a state can already occur while that state's onentry executable content is still processing. Hence, we end up with more parallelism than expected. Is this the intended behavior? From the SCXML specification I actually cannot find anything that either allows or prevents this interpretation. So I am also curious how this behavior is justified wrt. to specs. Kind regards, Johannes Hi Johannes, Great to see you looking into commons scxml! I've been away for a while on holiday so sorry for the late feedback on this and the other issues you reported. I haven't had time yet to dive into these but will look into them shortly. Regards, Ate - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [scxml] profiling scxml commons
On 18-06-14 09:42, R.C. Hoekstra wrote:
Hi all @ scxml commons.
We had some profiling done on our scxml multi agent simulation project. Our
issue is that scxml is too slow. We need about 100,000 instances of scxml
engines for a multi agent simulation, and tests show that the approach with
scxml is over 10 times slower than an alternative but less flexible approach.
Still, the flexibility of the scxml commons project serves us very well, so we
need to look for ways to improve the performance.
Great, and already thanks a lot for the valuable feedback and testing.
I think there is definitely room for improvements, and I'd be happy to help out
and already can take care of some of your suggestions below.
More inline comments below.
For our project setup see my mailing to this list on Fri, 30 May, 20:45.
We have the following tips and improvements:
1) Now, there's a logger applied for each instance, which is inefficient.
Make default Log in SimpleContext static. In
SCXMLExecutionContext/SCXMLExecutor, it can be static final even.
public class SimpleContext implements Context, Serializable {
/** Implementation independent log category. */
private static final Log DEFAULT_LOG = LogFactory.getLog(Context.class);
private Log log = DEFAULT_LOG;
Sure, will take care of this.
2) SimpleContext containsKey() + get() to get()
you can rewrite SimpleContext to:
public Object get(final String name) {
Object localValue = getVars().get(name);
if (localValue!=null) {
return localValue;
} else if (parent != null) {
return parent.get(name);
} else {
return null;
}
}
+1, also a trivial improvement, thanks.
We think item 1) & 2) will lead to a 30-50% improvement in our scenario, and
they are very simple to apply.
3) Other issues we are not sure about:
- Status.getAllStates can probably be cached: Difficult to determine if this
can be done since the states member is writable from outside and not sure when
this getAllStates() cache should be invalidated. But it takes up quite some
time.
Yeah, I think we can add some caching here, but as you already indicate, the
underlying states map is writable so it really depends on how often the
#getAllStates() method is invoked (extra) between updates against the states map
how much gain you'll receive.
But it is something I'll look into and try to add some caching.
- SCXMLSemanticsImpl.isLegalConfig is probably a paranoia check, can we disable
it?
It is a paranoia check yes, so if you are sure all your possible statemachine
transitions will end up legal anyhow, this check could be disabled.
I can add an option to configure this, but will keep it enabled by default.
Of course, you already could customize (extend) the current SCXMLSemanticsImpl
right now and overwrite this method to do nothing right now.
But adding a configurable option for this is a simply improvement I'm happy to
add.
4) Some questions about further speed improvements:
4a) scripting:
In the configuration as given, about 10% is spend in JEXL scripting. Depending
on how much we want to do with that, we could switch to another scripting
implementation (would require some benchmarking) or maybe move some of the
scripts into the Java domain.
Do you guys have any clues about which of the provided scripting
implementations is expected to be the fastest? Are there other possibilities to
improve the scripting performance?
I suggest trying out and testing the Groovy scripting instead. For *our*
use-cases it turned out to be faster (about 30%), but it expect it depends on
the specific evaluations you need to do.
If you try out the Groovy scripting it would be great if you can report back
your results here.
4b) initializing / common stuff:
What happens now is that each StateMachine engine (SCXMLExecutor) is
instantiated a thousand times, once for each agent. Maybe it's possible to move
some of the stuff to some common initialization where it is now done for each
agent. Do you see any opportunities here?
This'll take some more time to look into.
It's probably possible to restructure the setup a bit to be more optimal for
your use-case, but I need to think about the consequences for other use-cases as
well. And take into account other/future functional changes which are still
needed to bring the Commons SCXML further in line with the specification.
To be honest about this, I haven't had much time the last two months to work on
Commons SCXML, too busy with other obligations.
But I expect to have more time in a few weeks time.
The easy improvements you proposed above, I will pick up shortly though within
the coming week or so.
Thank again for the feedback and keep it coming :)
Regards,
Ate
Thanks,
kind regards,
Rinke Hoekstra.
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For addi
Re: [SCXML] our project setup: any tips specifically on performance/speed?
Hi Rinke, First of all, I've prefixed my reply with [SCXML] which is the convention on the Apache Commons lists so we can easily group and identify specific component related messages. I've added more specific comments inline below. On 09-05-14 11:40, R.C. Hoekstra wrote: Hi list, As written before, We're a university team of scientists working on multi agent simulations of tropical diseases for a world health organization project. A disease can be considered as a state machine, with the patient going through various states and transitions, each triggering new events. We've managed to make a working example of a xml file where a patient is going through various stages of the disease, including treatments with medicine. Our most important concern at the moment is: how efficient is it? Our aim is a multi agent simulation with possibly a few 100,000 of instances of a State Machine engine (SCXMLExecutor). I'd like to share the code setup with you guys, and maybe you can give some clues on how efficient it will be in terms of performance/speed, and maybe some hints if an alternative approach would be better? Maybe, but its a bit difficult in the abstract without having more concrete information on how you setup the project and certain usages. If you have the code publicly viewable it will definitely be helpful if you can share that. Also very important (but that should become clear if we can view the code) is which version of Commons SCXML you've set this up. As you know, the current SCXML trunk is a major rewrite compared to the old and outdated 0.9 release. If you currently are still using the 0.9 release, it might be difficult (certainly to me) to provide concrete feedback and help as I'm only focusing on the trunk 2.0 version. general setup we have a Population object (a wrapped list) containing all agent objects. Each agent is assigned an SCXMLExecutor as the engine, so there are many instances of SCXMLExecutor. We use the default JexlEvaluator, and each SCXMLExecutor gets the agent it belongs to assigned to the rootContext, so the agent's properties can be accessed from the scxml file. Transitions Our transitions are usually of a special type: a patient usually stays x days in a certain state, after which the transition takes place. The x days is determined on basis of drawing a random number from a statistical distribution. There is usually more than one possible transition; each with different probabilities. So the scxml file must contain the following information: * distribution name and parameters to determine the time until next transition. * A number coupled to each possible transition indicating the likelyhood that it happens. With potentially a 100K+ agents/SCXML instances concurrently, running for x number of days, I can imagine memory becoming an issue. Or maybe not. Are you (intending) to use some level of SCXML state serialization/de-serialization to keep memory footprint under control, or is everything expected to be kept running in memory? What are your environment (hardware) conditions/constraints? We solved this in the following way: * distribution name, mean and variance parameters, and chances are defined in the datamodel as single variables: in each state's onentry we set these variables with the values specific for that state, via the assign tag. The chances variable is defined as an array: * The state's onentry also contains a send tag. Send passes the agent's id, the forementioned variables and the event concerned. The send message is captured by our own implementation of EventDispatcher. This does two things: ** It draws the random time based on the passed distribution parameters. It schedules this in our own discreet event manager. When the desired time has passed, the discreet event manager passes the correct event back to the correct SCXMLExecutor instance. ** It determines which transition will be chosen by drawing a random number on basis of the chances array. This results in an index number of the transition to be chosen. This index number is passed as payload to the event. The scxml file checks this index number in the cond attribute of the transitions. Performance wise, I don't think the SCXML engine itself likely becoming an issue, but maybe your custom EventDispatcher/event-manager interaction might, certainly if these (all?) have to run on separate threads. You probably need or already have implemented some custom instance-to-event mapping solution for this? Using 100K+ separate threads isn't likely to work ;) Agent properties: Each disease state also has its effect on the agent's properties, for example the infectivity of the agent, or its fitness. The agent was passed to the rootContext, so the onentry of each state contains code to set the agent's properties specific to that state: agent.infectivity = 1 This is our overall approach. I'd be happy to receive any comments; specifically tips regarding the expected speed/perf
Re: scxml: planning and versions
Hi Rinke, On 19-04-14 22:15, R.C. Hoekstra wrote: Hi Ate, Woonsan, thanks for the long answer; sorry for my late reply, I was away for a few days. Good to hear you are really interested in our use-case, Ate. You're asking what specific specification features we will be using now, or in the near future. To be honest; I don't know yet. At the moment we are still in the stage of settings things up, and we are exploring all the possibilities scxml offers to our project. OK, that is already good to know :) Because to launch out here about our project features wouldn't fit anymore in the subject of this thread, I will soon post a subject about our project, and then maybe you guys can advise us some more on the best features to use. Great, looking forward to your email. FYI: I'll be away on a trip the coming 10 days, with little to no connectivity, so my feedback might come in only after I return. Regards, Ate best regards, Rinke - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: SCXML2 Serialization
Hi Francis, Thanks for the example test code, it helped me detect a bug in the state machine running status management which I already fixed, see [1]. Can you test and verify this now works for you? (note: you'll have to use SCXML trunk). I've one more comment inline below. Regards, Ate [1] https://issues.apache.org/jira/browse/SCXML-202 On 16-04-14 22:14, ten...@free.fr wrote: Thanks for your reply Ate. I want to serialize/deserialize a SCXML 'session' for this use case : Into a transactional server, a request is processed by a thread. An ID is retrieved from the message, with this ID the server loads a context (from a redis store) and instantiates a new 'Executor' with it's associated SCXML file and saved instance. I'll use invokers to call external functions or new a SCXML 'processor', I don't expect them to still be running after the state machine stabilized. You said : "But then you should not set the statemachine again (after attachInstance) as that will re-initialize the SCInstance itself" so I don't have to do this "executor.setStateMachine(scxml);"because scxml is serialized with the scInstance. But if I need to register a listener (addListener) or if I have custom actions, are they serialized too? No, SCXMLListeners are also not serialized. The reasoning for this is that, like with the Invokers, and all other interface based injected external objects, there is no way to determine and detect what they might end up serializing, if even possible. And they might be referenced themselves by other non-serialized objects which 'reference link' would get borked and broken after de-serialization. So you'll have to re-register listeners again as well. That is just the only save and stable way to do this. Note: the SCXMLListeners are 'registered' on the internal SCXML element id's and not the serialized elements themselves, so if you would not have to re-create SCXMLExecutor, *then* there is no need to re-register anything. In the example I do 'setInitialState(executor, "paused");' because the call to go resets the state and I know that 'paused' is the last state. Of course I want to 'return' in the same state I left off. Without a call of the go function, the state machine seems to be frozen. That was because of the bug I now fixed. AFAIK the example code you provided now 'works'. Thanks, Regards Francis. - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: SCXML2 Serialization
Hi Francis, On 17-04-14 07:48, ten...@free.fr wrote: Hi Ate, I put Simple1.java and Simple1.xml here : http://tendaf.free.fr/ I'll try to make some time tomorrow to test drive your example. Regards, Ate When I run the program (second time) the fsm is frozen : First time : After creation [startIngTrs.processMsg is running : true message:message1 serialize.. Process finished with exit code 0 Second time : Loading simple1 Deserialize.. After creation [startIngTrs.waitMsg is running : false message:message2 Process finished with exit code 0 Thanks, Regards Francis. Thanks for your reply Ate. I want to serialize/deserialize a SCXML 'session' for this use case : Into a transactional server, a request is processed by a thread. An ID is retrieved from the message, with this ID the server loads a context (from a redis store) and instantiates a new 'Executor' with it's associated SCXML file and saved instance. I'll use invokers to call external functions or new a SCXML 'processor', I don't expect them to still be running after the state machine stabilized. You said : "But then you should not set the statemachine again (after attachInstance) as that will re-initialize the SCInstance itself" so I don't have to do this "executor.setStateMachine(scxml);"because scxml is serialized with the scInstance. But if I need to register a listener (addListener) or if I have custom actions, are they serialized too? In the example I do 'setInitialState(executor, "paused");' because the call to go resets the state and I know that 'paused' is the last state. Of course I want to 'return' in the same state I left off. Without a call of the go function, the state machine seems to be frozen. Thanks, Regards Francis. - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: SCXML2 Serialization
Hi Woonsan,
On 16-04-14 15:49, Woonsan Ko wrote:
Hi Francis,
I think the best practices are to serialize either o.a.c.s.SCXMLExecutor [1] or
o.a.c.s.model.SCXML instances. Both cases are well-maintained in test code. [2]
Actually, since the last milestone SCXMLExecutor no longer is serializable :)
See also https://issues.apache.org/jira/browse/SCXML-197
I still need to provide updated documentation for this, but the SCXMLTestHelper
[2] class has been (and had to be) updated for this changed usage.
In your case, you can probably (de)serialize SCXMLExecutor instance directly to
store/load the execution context.
Also, as far as I can see, SCXMLExecutor doesn't provide #(at|de)tachInstance()
methods and I don't think it would do even later because SCInstance doesn't
necessarily have full information about the current execution context.
So, please (de)serialize the SCXMLExecutor instance instead.
You need to update to the latest milestone 1 or trunk, then you'll see the new
attach/detach instance features ;)
Cheers,
Woonsan
[1] http://commons.apache.org/proper/commons-scxml/faq.html#serializability
[2]
http://svn.apache.org/repos/asf/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml2/SCXMLTestHelper.java
On Wednesday, April 16, 2014 9:07 AM, "ten...@free.fr" wrote:
Hi all,
I would like to know the best practice to serialize/deserialize SCXML fsm.
I do this during the creation of the SCXML executor, scInstace is the
serialized context:
List customActions = new ArrayList();
CustomAction ca =
new CustomAction("http://my.custom-actions.domain/CUSTOM1";,
"hello", Hello.class);
customActions.add(ca);
JexlEvaluator evaluator = new JexlEvaluator();
try {
scxml = SCXMLReader.read(StopWatch.class.getClassLoader().
} catch (Exception e) {
e.printStackTrace();
throw e;
}
executor = null;
try {
executor = new SCXMLExecutor(evaluator, null, new
SimpleErrorReporter());
if (scInstance != null) {
// serialized context use it
executor.attachInstance(scInstance);
executor.registerInvokerClass("x-test",
DummyInvoker.class);
executor.setStateMachine(scxml);
executor.go();
setInitialState(executor, "paused");
} else {
// new context
Context rootContext = new JexlContext();
rootContext.set("var1", "value1");
executor.registerInvokerClass("x-test",
DummyInvoker.class);
executor.setStateMachine(scxml);
executor.setRootContext(rootContext);
executor.go();
}
} catch (ModelException me) {
// Executor initialization failed, because the
// state machine specified has inconsistencies
me.printStackTrace();
}
I serialize executor.detachInstance(). It's seem to work, but is it the right
way to restart a SCXML 'session' ?
Thanks
Francis.
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
Re: SCXML2 Serialization
Hi Francis,
There are a few things not right or needed in your approach below.
I've provided comments inline.
On 16-04-14 15:07, ten...@free.fr wrote:
Hi all,
I would like to know the best practice to serialize/deserialize SCXML fsm.
I do this during the creation of the SCXML executor, scInstace is the
serialized context:
List customActions = new ArrayList();
CustomAction ca =
new CustomAction("http://my.custom-actions.domain/CUSTOM1";,
"hello", Hello.class);
customActions.add(ca);
JexlEvaluator evaluator = new JexlEvaluator();
try {
scxml = SCXMLReader.read(StopWatch.class.getClassLoader().
} catch (Exception e) {
e.printStackTrace();
throw e;
}
executor = null;
try {
executor = new SCXMLExecutor(evaluator, null, new
SimpleErrorReporter());
While you can recreate SCXMLExecutor each time, this is not the intended usage.
The SCXMLExecutor holds the external event queue. If you are using Invokers, and
you *do* in your example, then these might still be (kept) 'running' while the
state machine itself is currently stabilized. So after a return from go() or
triggerEvent(). And these invokers might send back events into the external
queue for further processing. So then you should keep hold of the SCXMLExecutor
instance, across serialization/deserialization of the SCInstance.
If you don't use Invokers, or don't expect them to still be running after the
state machine stabilized (which might be the case in your example?) then I guess
recreating the SCXMLExecutor is fine. But then you should not set the
statemachine again (after attachIstance) as that will re-initialize the
SCInstance itself. Same goes for calling go() again or otherwise re-initializing
the current state. What would be the point of serializing in that case anyway?
Note also, the statemachine is automatically serialized together with the
SCInstance, so you actually don't need to set it again.
if (scInstance != null) {
// serialized context use it
executor.attachInstance(scInstance);
executor.registerInvokerClass("x-test",
DummyInvoker.class);
executor.setStateMachine(scxml);
this shouldn't be done as it will re-initialize the SCInstance state
executor.go();
this does the same, so definitely shouldn't be done either, because this way
there is no 'state' retained from what you serialized before
setInitialState(executor, "paused");
same goes for this: if you re-attach the instance, I assume you would want to
'return' in the same state you left off, right?
} else {
// new context
Context rootContext = new JexlContext();
rootContext.set("var1", "value1");
executor.registerInvokerClass("x-test",
DummyInvoker.class);
executor.setStateMachine(scxml);
executor.setRootContext(rootContext);
executor.go();
This initialization part is fine
}
} catch (ModelException me) {
// Executor initialization failed, because the
// state machine specified has inconsistencies
me.printStackTrace();
}
I serialize executor.detachInstance(). It's seem to work, but is it the right
way to restart a SCXML 'session' ?
See comments above. You're almost good but especially need to think about the
Invoker use-cases and if that might require you to keep hold of the
SCXMLExecutor instance.
Regards, Ate
Thanks
Francis.
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
Re: scxml: planning and versions
Hi Rinke, On 15-04-14 11:29, R.C. Hoekstra wrote: Hi all @ commons scxml, We're a university team of scientists working on multi agent simulations of tropical diseases for a world health organization project. A disease can be considered as a state machine, with the patient going through various states and transitions, each triggering new events. Interesting use-case which I definitely like to hear more details about! For our project we're diving into commons scxml. However I'm a bit confused about what version would be best to use. I'm a bit afraid that the 0.9 official release is so much outdated that it will not be compatible with the coming release, so we would end up with lots of changes to be made when updating. On the other hand working on a release which is still under development or unstable doesn't seem a good idea. Is the J6 branch on the svn.apache.org repository a good idea (1.0)? You better no longer start with the 0.9 release. It is outdated for sure and no longer actively maintained. But true enough, the 2.0 development hasn't completely stabilized out either. The J6 branch won't give you much benefit above the 0.9 release though: it is about just as outdated, and neither forwards compatible with the the W3C SCXML specification, nor the current 2.0 development in trunk for that matter. However, the latest milestone tag M1 towards the 2.0 release should give you a reasonable stable and reliable basis to start with. So much so that we actually are already using it in our product (see [1], slides 14-15 for some background on our use-case). And as Woonsan just emailed and which I'm just repeating here for completeness: instructions to get started with the M1 milestone can be found in an earlier email I send out to this list [2]. Anyway, it really depends on which of the SCXML specification features you need right now, today, or possibly very soon. As indicated on the roadmap [3], not everything is completely implemented or properly aligned with the requirements of the specification yet. Especially certain aspects around the datamodel handling, external communications and specific expression (language) features still needs some major changes and improvements. However, except for some temporarily dropped language features (milestone 0), most if not all features available from the 0.9 release still also work in the current 2.0 trunk, so from an SCXML semantics perspective you're far better off with the latest milestone already. The real significant changes so far are in the SCXML document model (with *added* capabilities, not so much dropped anything other than now being more in line with the specification), the processing algorithm, and the internal APIs. We are aggressively working towards further improving the alignment with the specification and I expect a next milestone tag might be possible in a few weeks time. This *will* result in additional changes, but mostly in the internal APIs, and probably some of the public/external interfaces (SCXMLExecutor etc.). So, upgrading between milestones will cause some coding impact, but should not change the SCXML state machine semantics itself, other than providing more support for and alignment to the specification. What definitely will help speed things up is if others can test drive it and provide feedback on what is working or not yet :) I'm definitely interested to hear more about your team requirements, what specific SCXML features you need and how you intend to integrate and execute Commons SCXML. If feasible I might be able to adjust the work planning if it would help you out with specific features sooner, if you are willing to test drive and provide feedback and/or maybe even directly contribute? Any help for sure is welcome and much appreciated! Can you give some clues in when the first 2.0 release can be expected? That is the toughest question to answer :) It depends: on the amount of time we can make free to work on this, the amount of help and contributions provided, and of course the technical hurdles still to solve. So I cannot give you a precise answer, but personally I think/hope it might be doable sometime this summer, or maybe even a bit sooner with the help and contributions of others ... Regards, Ate [1] http://events.linuxfoundation.org/sites/events/files/slides/ApacheConUS2014%20-%20Apache%20Commons%20SCXML%202.0.pdf [2] http://mail-archives.apache.org/mod_mbox/commons-user/201404.mbox/%3C533D4314.40805%40douma.nu%3E [3] http://commons.apache.org/proper/commons-scxml/roadmap.html Thanks, Rinke by the way: thanks for all the good work done. I think it is a great project. Thanks, great to hear you like it! - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org ---
Re: SCXML retrieve root context
On 12-04-14 21:46, ten...@free.fr wrote:
Thank you for your help Ate, it works very well, I still have a long way to go
in understanding SCXML..
No problem, I'd be happy to help you out further if you have more questions.
If you haven't seen them yet, the slides of my presentation I gave at the
ApacheCon last week might also be helpful [1], especially page 9-13.
I'll update the SCXML website sometime soon to provide a direct link to these
slides as well.
Regards, Ate
[1]
http://events.linuxfoundation.org/sites/events/files/slides/ApacheConUS2014%20-%20Apache%20Commons%20SCXML%202.0.pdf
Francis,
On 12-04-14 10:28, ten...@free.fr wrote:
Hi,
I would like to know if it's possible to retrieve the rootcontext given during
the creation of an SCXMLExecutor inside a custon action (i.e. Hello.class
example).
Yes you can. There isn't a direct API for it but its easy to retrieve the root
context with:
@Override
public void execute(ActionExecutionContext exctx) throws ModelException,
SCXMLExpressionException {
Context context = exctx.getGlobalContext();
while (context.getParent() != null) {
context = context.getParent();
}
// context now references the root context
...
}
The above starts with the global context (the one used and reserved for the
root/script element) and walks the parent tree up. Currently only the system
context sits between the root and global context.
HTH, Ate
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
Re: SCXML retrieve root context
On 12-04-14 10:28, ten...@free.fr wrote:
Hi,
I would like to know if it's possible to retrieve the rootcontext given during
the creation of an SCXMLExecutor inside a custon action (i.e. Hello.class
example).
Yes you can. There isn't a direct API for it but its easy to retrieve the root
context with:
@Override
public void execute(ActionExecutionContext exctx) throws ModelException,
SCXMLExpressionException {
Context context = exctx.getGlobalContext();
while (context.getParent() != null) {
context = context.getParent();
}
// context now references the root context
...
}
The above starts with the global context (the one used and reserved for the
root/script element) and walks the parent tree up. Currently only the system
context sits between the root and global context.
HTH, Ate
Thanks,
Francis.
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
[SCXML] developer heads-up: Commons SCXML 2.0-M1 (milestone 1) tag now available - please test
SCXML developers, I've just created the second Commons SCXML 2.0-M1 milestone tag on the roadmap towards Commons SCXML 2.0 [1]. This milestone incorporates some major (and drastic) changes, and completely replaces the old SCXMLSemantics with a new implementation which now is fully compliant to the current SCXML specification [2],[3]. Actually, its even a little bit ahead of the specification right now, as I discovered a few edge-case issues in the specification, which I reported and discussed with the specification group [4], and which have been solved already in the Apache Commons SCXML implementation :) Also important to note is that the internal structure of many of the controlling parts of the engine has been refactored, towards a much cleaner separation of concern [5]. Finally, most of the core SCXML Document model has been updated to be now fully compliant with the SCXML specification as well [6]. There are certainly still several hurdles to take and additional features to be implemented, which will be the subject of the next milestone(s) ahead. Please check out the roadmap overview [1] for further details. It would be great if you can test this new milestone and report anything which doesn't work as expected, besides the already planned fixes and improvements of course. To get an overview of all the issues resolved for version 2.0 since the previous milestone 0 (2014-03-11) up to today you can use the JIRA query in [7]. To be able to test drive this tag, you'll first have to checkout the code using: $ svn co https://svn.apache.org/repos/asf/commons/proper/scxml/tags/commons-scxml2-2.0-M1 build and install to your local Maven repository: $ cd commons-scxml2-2.0-M1 & mvn install and then in your Maven project add the following dependency configuration: org.apache.commons commons-scxml2 2.0-M1 Note (again) also the change of both the groupId and artifactId from commons-scxml:commons-scxml to org.apache.commons:commons-scmxl2. Subsequent milestone tags will provide new and changed functionalities as indicated on the roadmap. Regards, Ate [1] http://commons.apache.org/proper/commons-scxml/roadmap.html [2] http://www.w3.org/TR/2014/CR-scxml-20140313/#AlgorithmforSCXMLInterpretation [3] https://issues.apache.org/jira/browse/SCXML-196 [4] http://lists.w3.org/Archives/Public/www-voice/ [5] https://issues.apache.org/jira/browse/SCXML-197 [6] https://issues.apache.org/jira/browse/SCXML-200 [7] https://issues.apache.org/jira/browse/SCXML-201?jql=fixVersion%20%3D%202.0%20AND%20project%20%3D%20SCXML%20AND%20resolved%20%3C%20%222014%2F04%2F04%22%20and%20resolved%20%3E%20%222014%2F03%2F11%22%20ORDER%20BY%20key%20DESC - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [ANNOUNCE] [ApacheCon NA2014] Using Apache Commons SCXML 2.0: a general-purpose and standards based state machine engine
On 26-02-14 23:24, Ate Douma wrote: On 26-02-14 15:04, Jim Barnett wrote: Ate, It's very good news that Commons SCXML is still active. Oh yes, and we have the intent to bring it back in line and compliance with the specification for the 2.0 release. I have been monitoring this list for a while and not seen any mention of it. You might have, if you also monitored the d...@commons.apache.org list :) That is where we have been discussing the reactivation of Commons SCXML. Commons SCXML has been kind of dormant for several years, with as result that the current implementation isn't really in sync or compliance with the latest specification. However, since last October we 'rebooted' the project (slowly) and started with basic cleanup and some initial fixes and minor improvements. And even not so minor improvements like preliminary Groovy scripting support. I'm now ready and about to come up with a plan and roadmap for more drastic changes in the internals and semantics of the SCXML processing, which are really needed to be able to get to spec compliance. FYI: I've just send out such plan and roadmap for Commons SCXML 2.0 on d...@commons.apache.org, see: http://markmail.org/message/k3zukfgnd23zwimg That'll take a bit for sur, but I've digested and dissected the specs now often enough to have a reasonable idea of what is required first :) Have you looked at the W3C test plan for SCXML http://www.w3.org/Voice/2013/scxml-irp/? Yes I did. And I definitely will start using and validating against it *once* we've reached a minimal level of spec compliance needed to even start executing those tests... Right now, its pointless to even try. Mind you: Commons SCXML *does* work nicely within its current limitations, and we (my company) actually already use it integrated in our product. But getting it spec compliant definitely is high on our list. I'd also be interested in knowing what optional features you plan to support. I haven't given that much thought yet. Getting the required features working is first priority. For now our focus is on getting Commons SCXML 2.0 compliant as 'plain' Java back-end engine only. I actually intend to first get rid of much of the now too old/outdated/incomplete stuff like Shale/JSF/Servlet/E4X support as they only complicate the effort in this phase. We can later rebuild support back in for such usages if/when there is enough interest for it (and concrete help doing it). Will you support the XML datamodel or the DOM Event I/O processor? The XPath/XML datamodel has been the only (type of) datamodel Commons SCXML supported. For sure we'll continue supporting that, and (need to) improve/fix it. I also have the intend to add Ecmascript+JSON datamodel support. I don't expect we'll add DOM Event I/O processor support any time soon though. Like I said above, our primary focus is on Java based back-end use-cases only and not front-end/browser integration. But of course, anyone with an itch, and the capacity to scratch it properly, is more than welcome to join the project and start helping out! Which is also one of the goals with my presentation at the ApacheCon: making the community aware of the re-activation of Commons SCXML, the roadmap we're working on and raising interest to participate and help out. Kind regards, Ate p.s. I probably will chime in on the www-vo...@w3.org list soon once I start hacking on the semantics of the SCXML processing :) Best Regards, Jim Barnett -Original Message- From: Ate Douma [mailto:a...@douma.nu] Sent: Wednesday, February 26, 2014 5:38 AM To: Commons Users List Subject: [ANNOUNCE] [ApacheCon NA2014] Using Apache Commons SCXML 2.0: a general-purpose and standards based state machine engine Just like to inform you all I'll be presenting on Commons SCXML 2.0 at ApacheCon North America 2014 (Denver, April 7-9). For details and schedule see: http://sched.co/1dlTw2L Regards, Ate - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [ANNOUNCE] [ApacheCon NA2014] Using Apache Commons SCXML 2.0: a general-purpose and standards based state machine engine
On 26-02-14 15:04, Jim Barnett wrote: Ate, It's very good news that Commons SCXML is still active. Oh yes, and we have the intent to bring it back in line and compliance with the specification for the 2.0 release. I have been monitoring this list for a while and not seen any mention of it. You might have, if you also monitored the d...@commons.apache.org list :) That is where we have been discussing the reactivation of Commons SCXML. Commons SCXML has been kind of dormant for several years, with as result that the current implementation isn't really in sync or compliance with the latest specification. However, since last October we 'rebooted' the project (slowly) and started with basic cleanup and some initial fixes and minor improvements. And even not so minor improvements like preliminary Groovy scripting support. I'm now ready and about to come up with a plan and roadmap for more drastic changes in the internals and semantics of the SCXML processing, which are really needed to be able to get to spec compliance. That'll take a bit for sur, but I've digested and dissected the specs now often enough to have a reasonable idea of what is required first :) Have you looked at the W3C test plan for SCXML http://www.w3.org/Voice/2013/scxml-irp/? Yes I did. And I definitely will start using and validating against it *once* we've reached a minimal level of spec compliance needed to even start executing those tests... Right now, its pointless to even try. Mind you: Commons SCXML *does* work nicely within its current limitations, and we (my company) actually already use it integrated in our product. But getting it spec compliant definitely is high on our list. I'd also be interested in knowing what optional features you plan to support. I haven't given that much thought yet. Getting the required features working is first priority. For now our focus is on getting Commons SCXML 2.0 compliant as 'plain' Java back-end engine only. I actually intend to first get rid of much of the now too old/outdated/incomplete stuff like Shale/JSF/Servlet/E4X support as they only complicate the effort in this phase. We can later rebuild support back in for such usages if/when there is enough interest for it (and concrete help doing it). Will you support the XML datamodel or the DOM Event I/O processor? The XPath/XML datamodel has been the only (type of) datamodel Commons SCXML supported. For sure we'll continue supporting that, and (need to) improve/fix it. I also have the intend to add Ecmascript+JSON datamodel support. I don't expect we'll add DOM Event I/O processor support any time soon though. Like I said above, our primary focus is on Java based back-end use-cases only and not front-end/browser integration. But of course, anyone with an itch, and the capacity to scratch it properly, is more than welcome to join the project and start helping out! Which is also one of the goals with my presentation at the ApacheCon: making the community aware of the re-activation of Commons SCXML, the roadmap we're working on and raising interest to participate and help out. Kind regards, Ate p.s. I probably will chime in on the www-vo...@w3.org list soon once I start hacking on the semantics of the SCXML processing :) Best Regards, Jim Barnett -Original Message- From: Ate Douma [mailto:a...@douma.nu] Sent: Wednesday, February 26, 2014 5:38 AM To: Commons Users List Subject: [ANNOUNCE] [ApacheCon NA2014] Using Apache Commons SCXML 2.0: a general-purpose and standards based state machine engine Just like to inform you all I'll be presenting on Commons SCXML 2.0 at ApacheCon North America 2014 (Denver, April 7-9). For details and schedule see: http://sched.co/1dlTw2L Regards, Ate - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
[ANNOUNCE] [ApacheCon NA2014] Using Apache Commons SCXML 2.0: a general-purpose and standards based state machine engine
Just like to inform you all I'll be presenting on Commons SCXML 2.0 at ApacheCon North America 2014 (Denver, April 7-9). For details and schedule see: http://sched.co/1dlTw2L Regards, Ate - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
