Author: gtrasuk
Date: Tue May 14 12:20:38 2013
New Revision: 1482317
URL: http://svn.apache.org/r1482317
Log:
Continued work on hierarchical state machine impl. Added JMX capability to
StarterServiceDeployer.
Added:
river/jtsk/skunk/surrogate/src/org/apache/river/container/deployer/StatusEvents.java
river/jtsk/skunk/surrogate/test/org/apache/river/container/hsm/HSMTestSuite.java
river/jtsk/skunk/surrogate/test/org/apache/river/container/hsm/TestSMSecondInterface.java
- copied, changed from r1427243,
river/jtsk/skunk/surrogate/test/org/apache/river/container/hsm/TestSMInterface.java
Removed:
river/jtsk/skunk/surrogate/test/org/apache/river/container/work/ThreadPoolExecutorTest.java
river/jtsk/skunk/surrogate/testfiles/testroot/test.log
Modified:
river/jtsk/skunk/surrogate/docs/StateMachine.txt
river/jtsk/skunk/surrogate/nbproject/build-impl.xml
river/jtsk/skunk/surrogate/nbproject/genfiles.properties
river/jtsk/skunk/surrogate/nbproject/project.xml
river/jtsk/skunk/surrogate/src/org/apache/river/container/Bootstrap.java
river/jtsk/skunk/surrogate/src/org/apache/river/container/Messages.properties
river/jtsk/skunk/surrogate/src/org/apache/river/container/Utils.java
river/jtsk/skunk/surrogate/src/org/apache/river/container/deployer/ApplicationEnvironment.java
river/jtsk/skunk/surrogate/src/org/apache/river/container/deployer/StarterServiceDeployer.java
river/jtsk/skunk/surrogate/src/org/apache/river/container/deployer/StarterServiceDeployerMXBean.java
river/jtsk/skunk/surrogate/src/org/apache/river/container/deployer/StarterServiceLifeCycle.java
river/jtsk/skunk/surrogate/src/org/apache/river/container/deployer/StarterServiceLifeCycleSM.java
river/jtsk/skunk/surrogate/src/org/apache/river/container/hsm/PlainStateMachineExecutor.java
river/jtsk/skunk/surrogate/src/org/apache/river/container/hsm/RootState.java
river/jtsk/skunk/surrogate/src/org/apache/river/container/hsm/StateMachineCompiler.java
river/jtsk/skunk/surrogate/src/org/apache/river/container/hsm/SubstateInfo.java
river/jtsk/skunk/surrogate/src/org/apache/river/container/work/BasicWorkManager.java
river/jtsk/skunk/surrogate/test/org/apache/river/container/hsm/PlainMachineExecutorTest.java
river/jtsk/skunk/surrogate/test/org/apache/river/container/hsm/ReturnTypeTest.java
river/jtsk/skunk/surrogate/test/org/apache/river/container/hsm/TestSM.java
Modified: river/jtsk/skunk/surrogate/docs/StateMachine.txt
URL:
http://svn.apache.org/viewvc/river/jtsk/skunk/surrogate/docs/StateMachine.txt?rev=1482317&r1=1482316&r2=1482317&view=diff
==============================================================================
--- river/jtsk/skunk/surrogate/docs/StateMachine.txt (original)
+++ river/jtsk/skunk/surrogate/docs/StateMachine.txt Tue May 14 12:20:38 2013
@@ -25,17 +25,15 @@ The model for the HSM is as follows:
- User sends an event by calling a method on a proxy that implements the
machine.
- An event is "run" on the current state hierarchy (top-level state and all
active substates).
-- Each event can trigger a transition (actually one or more) by calling the
-'transition' method on the machine implementation. Perhaps this is a mistake
-
-it might be better if the transition was executed by guard conditions and not
-by a method call. Event can also imply a transition.
+- Each event can trigger a transition (actually one or more) by invoking a
method
+that has an @Transition annotation that lists the set of states that should be
+activated after the event is run.
- The state can have sub-states, so when we transition to a state, a sub-state
may also become active, and will need to have its entry code run. The
sub-state
might be a fresh state on entry, or might have been retained from the last time
the state was active.
- Each state may have an "on-entry" and "on-exit" function, which will be
executed
-by the transition code. These functions could conceivably queue up
transitions
-that need to be executed (maybe this is a problem?). Entry and exit code
+by the transition code. Entry and exit code
typically sets up timers or toggles outputs.
- Each state can have zero or more "guard" methods, each specifying a
transition.
A guard method is run after every event is executed, and determines whether the
@@ -44,9 +42,4 @@ guard method returns true, the correspon
could also be seen as "anonymous" transitions, as they are not attached to any
particular event.
-Thoughts:
-The idea of the machine's actions queuing their own events and transitions
-leads to a problem of re-entrancy, where we start to need complicated
-mechanisms (e.g. different proxies for external vs internal access). It's
-probably a bad idea.
