- For Guard and Transition change call stach to be fully
reactive from executor. Some changed signatures similarly
what was needed for reactive Actions.
- Disabling one smoke test to get figure out later as
something is broken somewhere, possible reactor bug...
- Relates #791
- First changes to introduce ReactiveGuard similar to work done
for ReactiveAction. User level interface is ReactiveGuard but internally
it is handled as its super type Function<StateContext<S, E>, Mono<Boolean>>.
- This change still keeps some calls as blocking which will get changed
in futher commits to get a full reactive chain.
- Touching only Transition to change guard signature, other use of blocking guard
internally need to get similar changes in next commits.
- Baby steps...
- Relates #791
- remove junit4 dependecies
- refactor the unit tests by junit5
- enhance the spring-statemachine-test and spring-statemachine-build-tests so they can work together with junit4/junit5
- relates #779
- Polish previous change to AbstractState by using a shared function
completionStateListenerSink to track completion sink as functionality
between entries to submachine/regions should be similar.
- Mostly relates to #743
- This commit changes a way how triggerless transitions are executed by
going via new doOnComplete method in StateListener which returns
Mono<Void>. This used to be a simple fire and forget subscribe via listener
and now fully handled via reactive chain when state is complete. Rest of
a changes are to tweak state actions to run parallel to be able to cancel
those and then follow and track when triggerless transitions need to be
executed.
- AbstractState still have some work to do for disposing things around
submachines which currently seem to break thins if handleStateDoOnComplete
is disposed when submachine state is exited. We'll leave this to get
fixed later.
- Add tag handling for junit5 which can be set via gradle build properties
statemachineIncludeTags and statemachineExcludeTags.
- Add BlockHound to build which can be activated via gradle build
property statemachineBlockHound.
- Add org.awaitility:awaitility to various test deps.
- Mostly relates to #734
- Move to use reactive methods and for now block
as concept is really blocking. Full reactive stuff
needs bigger overhaul.
- Fix event issues in DistributedStateMachine as these
caused issues when StateMachineTestPlan were changed to
send events via reactive methods.
- Relates #744
- Relates #750
- Remove use of statemachine assertj assertions to prepare move
- Move statemachine assertj assertion to spring-statemachine-test
- Polish some tests and user TestUtils from core tests
- Remove most of a deprecation warning from core tests
- Relates #744
- Add stateDoFunction, stateEntryFunction and stateExitFunction methods
taking Function with a state to register reactive actions.
- Don't yet to a full take on all similar action methods as we need
to think about how these should be named and what old methods to
depecate.
- Relates #743
- This first commit related to reactive action support basically changes internal
logic away from original Action interface which really is just
a Consumer<StateContext> but it originates pre jdk8 era.
Reactive equivalent internally is now Function<StateContext<S, E>, Mono<Void>>.
- Essentially actions will now get executed with a reactor chain fully.
- Fix StateMachineExecutorTransit in AbstractStateMachine to be full reactive
chain which were needed to get reactive actions working. This also put
StateContextTests back to its original state.
- Add typesafe interface ReactiveAction which simply wraps
Function<StateContext<S, E>, Mono<Void>> and add this to transitions with
actionFunction() as a concept. This will be added to states in next
commits if actionFunction() as a concept works.
- Polish various things and issues which were not addressed with initial reactive commit.
- Disable ActionSecurityTests for now as secured Action bean now breaks because it's
internally wrapped into a Function and Spring Security doesn't see it anymore.
Security like this needs a bit of a overhaul which can be done later.
- State do actions which are done via scheduling needs some work as now we just do
a subscribe which is probably a bit wrong. There's going to be more work for
scheduling so this also can be left later stages.
- Relates #743
- Change to Boot 2.2.x to pick upcoming series.
- Introduce Awaitility to tests
- Introduce new StateMachineEventResult concept in favor of boolean
when sending events. This result interface will have richer information
what happens when event is processed as previously we simply had boolean
flag telling if even was accepted. With StateMachineEventResult we can
can provide more information like if event was deferred and which region
provided this message.
- Deprecate old event methods and add new reactive event methods which now
return a Flux of StateMachineEventResult's. This concept then allows
to send Flux of events to a machine.
- State exit/entry now return Mono<Void>
- Refactor component lifecycle to be reactive as old start/stop would
not work anymore in a reactive statemachine simply because start may
cause changes and execute flow's.
- To ease testing add internal assertj assertions for some classes. This
work is kept in a test classes for time being to get move to public
spring-statemachine-test when things are more mature.
- Overhaul StateMachineExecutor interface and replace DefaultStateMachineExecutor
with ReactiveStateMachineExecutor.
- New ReactiveLifecycleManager which is kinda reactive replacement of some internals
of a LifecycleObjectSupport. Needed as components are reactively started and
stopped during a machine execution.
- New RegionExecutionPolicy concept which is an attempt to introduce parallel config
idea to a regions. Previously this was just naively handled with TaskExecutor which
never worked perfectly while working through reactor now seem to provide more
consistent results.
- Some test has been changed to reflect changes in a StateMachineExecutor. Also execution
using reactor made some changes to state notifications which now seem to be
more consistent(aka. previously parallel execution might have given notifications
in wrong order and in some cases kinda bogus changes).
- New turnstile reactive sample which is just start of a reactive sample to show
concept with webflux.
- Don't yet really add any docs as things are in-flight.
- Fixes#740
