You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Ant Kutschera (JIRA)" <ji...@apache.org> on 2010/08/27 11:56:53 UTC
[jira] Created: (SCXML-156) Need a better way of setting initial
state in instances of SCXMLExecutor
Need a better way of setting initial state in instances of SCXMLExecutor
------------------------------------------------------------------------
Key: SCXML-156
URL: https://issues.apache.org/jira/browse/SCXML-156
Project: Commons SCXML
Issue Type: Improvement
Affects Versions: 0.9
Environment: local j2se
Reporter: Ant Kutschera
Priority: Minor
Example:
I have states RESERVED->BOOKED->PAID. The initial state is RESERVED. I create a business entity which has this state and I need to persist it in state BOOKED.
I persist the state as a varchar / String. I don't want to persist a state machine in my database.
When I load the entity in order to update the state to "PAID", I need to instantiate the state machine, and update the state to "BOOKED", since that is the status my object really has.
I can do this, only by modifying the InitialTarget of the SCXML using the API. That isn't nice, because I only want one instance of SCXML, because loading the XML is expensive in terms of time/cpu etc. The solution I've used now is to do the update in a synchronized block, while being synchronized on the SCXML instance, and then after I instantiate the SCXMLExecutor, I put the state back in the SCXML to the original initial state.
Ideally, I would be able to pass the "starting state" to the constructor of the SCXMLExecutor, to indicate that I am starting from a partially run workflow, if that makes sense.
See this blog article too: http://blog.maxant.co.uk/pebble/2010/08/26/1282857660000.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SCXML-156) Need a better way of
setting initial state in instances of SCXMLExecutor
Posted by "Rahul Akolkar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SCXML-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12903426#action_12903426 ]
Rahul Akolkar edited comment on SCXML-156 at 8/27/10 10:29 AM:
---------------------------------------------------------------
This can simply be done along these lines (Java 1.4):
{code:java}
public void setCurrentState(SCXMLExecutor exec, String state) {
Set states = exec.getCurrentStatus().getStates();
states.clear();
TransitionTarget tt = (TransitionTarget) exec.getStateMachine().getTargets().get(state);
states.add(tt);
}
{code}
You can find a more resilient version of the above method here which uses generics (search for "setCurrentState"):
http://svn.apache.org/repos/asf/commons/proper/scxml/branches/J6/src/test/java/org/apache/commons/scxml/SCXMLTestHelper.java
WRT the AbstractStateMachine class, that was built as the simplest pattern, I wouldn't put it to any serious use.
was (Author: rahul@apache.org):
This can simply be done along these lines (Java 1.4):
public void setCurrentState(SCXMLExecutor exec, String state) {
Set states = exec.getCurrentStatus().getStates();
states.clear();
TransitionTarget tt = (TransitionTarget) exec.getStateMachine().getTargets().get(state);
states.add(tt);
}
You can find a more resilient version of the above method here which uses generics (search for "setCurrentState"):
http://svn.apache.org/repos/asf/commons/proper/scxml/branches/J6/src/test/java/org/apache/commons/scxml/SCXMLTestHelper.java
WRT the AbstractStateMachine class, that was built as the simplest pattern, I wouldn't put it to any serious use.
> Need a better way of setting initial state in instances of SCXMLExecutor
> ------------------------------------------------------------------------
>
> Key: SCXML-156
> URL: https://issues.apache.org/jira/browse/SCXML-156
> Project: Commons SCXML
> Issue Type: Improvement
> Affects Versions: 0.9
> Environment: local j2se
> Reporter: Ant Kutschera
> Priority: Minor
>
> Example:
> I have states RESERVED->BOOKED->PAID. The initial state is RESERVED. I create a business entity which has this state and I need to persist it in state BOOKED.
> I persist the state as a varchar / String. I don't want to persist a state machine in my database.
> When I load the entity in order to update the state to "PAID", I need to instantiate the state machine, and update the state to "BOOKED", since that is the status my object really has.
> I can do this, only by modifying the InitialTarget of the SCXML using the API. That isn't nice, because I only want one instance of SCXML, because loading the XML is expensive in terms of time/cpu etc. The solution I've used now is to do the update in a synchronized block, while being synchronized on the SCXML instance, and then after I instantiate the SCXMLExecutor, I put the state back in the SCXML to the original initial state.
> Ideally, I would be able to pass the "starting state" to the constructor of the SCXMLExecutor, to indicate that I am starting from a partially run workflow, if that makes sense.
> See this blog article too: http://blog.maxant.co.uk/pebble/2010/08/26/1282857660000.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SCXML-156) Need a better way of setting initial
state in instances of SCXMLExecutor
Posted by "Ant Kutschera (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SCXML-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12903522#action_12903522 ]
Ant Kutschera commented on SCXML-156:
-------------------------------------
OK, cool, and makes sense, although the Javadoc isn't too intuitive.
Maybe for the future you could consider making an explicit method for setting the current state, which encapsulates this? And the Javadoc could clearly state what the method is for.
Anyway, I know its not part of this issue, but is there a way to get SCXML to throw an exception if you trigger an illegal transition?
> Need a better way of setting initial state in instances of SCXMLExecutor
> ------------------------------------------------------------------------
>
> Key: SCXML-156
> URL: https://issues.apache.org/jira/browse/SCXML-156
> Project: Commons SCXML
> Issue Type: Improvement
> Affects Versions: 0.9
> Environment: local j2se
> Reporter: Ant Kutschera
> Priority: Minor
>
> Example:
> I have states RESERVED->BOOKED->PAID. The initial state is RESERVED. I create a business entity which has this state and I need to persist it in state BOOKED.
> I persist the state as a varchar / String. I don't want to persist a state machine in my database.
> When I load the entity in order to update the state to "PAID", I need to instantiate the state machine, and update the state to "BOOKED", since that is the status my object really has.
> I can do this, only by modifying the InitialTarget of the SCXML using the API. That isn't nice, because I only want one instance of SCXML, because loading the XML is expensive in terms of time/cpu etc. The solution I've used now is to do the update in a synchronized block, while being synchronized on the SCXML instance, and then after I instantiate the SCXMLExecutor, I put the state back in the SCXML to the original initial state.
> Ideally, I would be able to pass the "starting state" to the constructor of the SCXMLExecutor, to indicate that I am starting from a partially run workflow, if that makes sense.
> See this blog article too: http://blog.maxant.co.uk/pebble/2010/08/26/1282857660000.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SCXML-156) Need a better way of setting initial
state in instances of SCXMLExecutor
Posted by "Rahul Akolkar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SCXML-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rahul Akolkar resolved SCXML-156.
---------------------------------
Resolution: Not A Problem
This can simply be done along these lines (Java 1.4):
public void setCurrentState(SCXMLExecutor exec, String state) {
Set states = exec.getCurrentStatus().getStates();
states.clear();
TransitionTarget tt = (TransitionTarget) exec.getStateMachine().getTargets().get(state);
states.add(tt);
}
You can find a more resilient version of the above method here which uses generics (search for "setCurrentState"):
http://svn.apache.org/repos/asf/commons/proper/scxml/branches/J6/src/test/java/org/apache/commons/scxml/SCXMLTestHelper.java
WRT the AbstractStateMachine class, that was built as the simplest pattern, I wouldn't put it to any serious use.
> Need a better way of setting initial state in instances of SCXMLExecutor
> ------------------------------------------------------------------------
>
> Key: SCXML-156
> URL: https://issues.apache.org/jira/browse/SCXML-156
> Project: Commons SCXML
> Issue Type: Improvement
> Affects Versions: 0.9
> Environment: local j2se
> Reporter: Ant Kutschera
> Priority: Minor
>
> Example:
> I have states RESERVED->BOOKED->PAID. The initial state is RESERVED. I create a business entity which has this state and I need to persist it in state BOOKED.
> I persist the state as a varchar / String. I don't want to persist a state machine in my database.
> When I load the entity in order to update the state to "PAID", I need to instantiate the state machine, and update the state to "BOOKED", since that is the status my object really has.
> I can do this, only by modifying the InitialTarget of the SCXML using the API. That isn't nice, because I only want one instance of SCXML, because loading the XML is expensive in terms of time/cpu etc. The solution I've used now is to do the update in a synchronized block, while being synchronized on the SCXML instance, and then after I instantiate the SCXMLExecutor, I put the state back in the SCXML to the original initial state.
> Ideally, I would be able to pass the "starting state" to the constructor of the SCXMLExecutor, to indicate that I am starting from a partially run workflow, if that makes sense.
> See this blog article too: http://blog.maxant.co.uk/pebble/2010/08/26/1282857660000.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.