- When comparing states that are of type Enum, the check
always fails causing the state machine to incorrectly
use the starting state regardless of where it was previously.
- Added unit test to test correct state is set on restart.
However, added changes have no effect for this test. The issue is being
caused elsewhere. When loading from JPA, ss.getId() instanceof S
is always false causing the previous state to never be set.
- Fixes#537
- Add new concepts around executing state do actions
allowing to use timeouts via StateDoActionPolicy.
- Global config per machine or via event headers.
- Backport #501
- Relates #504
- Currently into as internal new feature, add state
completed concecept and use it in various places.
- Main focus for this commit is to add support using
anonymous transitions with state do actions which
requires proper completion schematics.
- Internal functionality here will probably expose to
user level in future releases using various other
concepts.
- Backport #466
- Relates #504
- Add new TransitionConflightPolicy and allow to configure
it via an adapter interfaces.
- For now, use it in TransitionComparator which sorts transitions
based on source states. This gives PARENT and CHILD sorting
and allows to choose conflicting transitions either from parent
or child.
- Add new sync thread used in submachines so that one thread is used
in a whole call stach per machine(regions still get their own as well
as a root machine).
- Fixes#456
- Naively with StateMachineConfigurerAdapter or EnumStateMachineConfigurerAdapter
only immediate super type were checked to find user level generics to
instruct IOC for proper resolvable types. This worked with almost all cases
except if user created new base type out from StateMachineConfigurerAdapter and
bean id didn't match what what was trying to get autowired if multiple adapters
were in use.
- Correctly find resolvable type as StateMachineConfigurerAdapter in ResolvableType
which finds an exact correct type to get generics.
- Fixes#454
- Now in AbstractPersistingStateMachineInterceptor it is possible
to use a Function to define which variables are persisted. This
is for cases where it is not desirable to persist some variables
for variours reasons.
- Relates to #423
- In AbstractStateMachine and DefaultStateMachineExecutor
do a little more synchronisation so that submachine is allowed
to do its run-to-completion before parent machine can do its
own transitions. This should fix use cases, when submachine
starts, does its transitions and actions, parent wont try to
do its own triggerless transtions.
- Adding some new tests and fixing one other sync issue with end state.
- Relates to #442
- Move away from thread local in favour of using
kryo pooling.
- New interface StateMachineSerialisationService
with KryoStateMachineSerialisationService.
- Try to work via constructors for instead of full blown
configuration as it looks like this may give enough
for users to customise.
- Relates to #437
- Fix wrong acquire logic in DefaultStatemachineService.
- Overhaul StateMachineRuntimePersister
- Change StateMachineRuntimePersister to extend
StateMachinePersist which should work better on
a bean level. Also add generic type T to it and
config where needed.
- Relates to #432
- Relates to #427
- Add new repository model for storing StateMachineContext
via a new StateMachineRepository.
- New StateMachineRuntimePersister interface to abstract needed
functionality to do a runtime machine persistence.
- As runtime persistence, as of now, is done via interceptors, define
JpaRepositoryStateMachinePersist and JpaPersistingStateMachineInterceptor
to define StateMachineRuntimePersister logic.
- Add new datajpapersist sample demonstrating new concepts.
- Keep tests related to jpa as there's not redis/mongo integration
implemented in this first iteration.
- As this is going to be WIP until features around this issues
are completed, docs, etc are not yet added. Also, interfaces and impls
are subject to change during a process.
- Relates to #423
- Relates to #426
- Relates to #427
- Makes things less chatty if BeanFactory is null in
StateMachineHandlerCallHelper as this is usually a case
with manual builders outside of app context.
- Backport #412
- Relates #307
- As passing in null context don't have any
meaning other than doing reset with pre-defined
behaviour which currently just resets back to
initial state and clears extended state variables.
Now Also clearing machine id back to null which is
anyway a default value.
- Backport #381
- Relates #307
- Fixing machine lifecycle logic when machine
is restored which effectively should not touch
any lifecycle methods as start/stop is
user level action.
- Remove start/stop from restore and attempt to
do same when root machine is started. This also
needed some further changes as some functionality
for restore was essentially broken
- Backport #386
- Relates #307
- Fix case where method was annotated with
@OnExtendedStateChanged(key = "V1"), V1 was
changed which didn't result call to that method.
- Backport #387
- Relates #307
- Change processor registration so that if @WithStateMachine is
used with 'id', 'name' is skipped because it defaults to 'stateMachine'
and would cause extra registration.
- Relates #307
- Backport #370
- Adding null check for current state
- Remove synchronization from scheduleEventQueueProcessing
method in executor. Looks like this sync is not really needed
and indeed may cause jvm level deadlocks if threads are used
for execution.
- Change how some internals in
AbstractStateMachine are synchronized
to limit changes for deadlock.
- Relates to #307
- Backport of #359#360
- Adding support for javaconfig/uml to define
actions for transitions leading out from a
choice or junction states.
- Support for action for incoming transition is
already implemented as it is defined as normal
transition.
- Backport #108
- Relates #307
- Executor is following anonymous transitions in a loop
and if there is an exception in actions with this transition,
effectively executor ended into infinite loop.
- No bailing out from this loop if we cannot continue.
- Backport #344
- Relates #307
- Trying to handle scenario where TimerTrigger keeps firing
even if machine is stopped or has moved away from its
hosting state.
- Explicitely handle trigger starts/stops in
DefaultStateMachineExecutor when executor itself
is started/stopped.
- Backport #321
- Relates to #307
