- Refactor so that we can create RepositoryState in one place
and then reference to it from JpaRepositoryTransition impls.
- New common top class BaseRepositoryEntity for entities
- Change RepositoryState and RepositoryTransition to be abstract
classes instead of interfaces.
- New custom StateMachineJackson2RepositoryPopulatorFactoryBean and
StateMachineJackson2ResourceReader handling json refs.
- Relates to #262
- Align related spring train deps
- Modify some other deps to get correct versions
- Some testing changes as boot 1.4.1 shuffled some
test stuff around.
- Fixed deprecations with newer boot and framework
- Fixes#256
- Initial infra for config abstraction with
Spring Data Repositories via RepositoryStateMachineModelFactory.
- Initial jpa impl.
- Initial jpa sample atop of H2 DB.
- Relates to #250
- First stage to add support for UI modeling via
eclipse uml2 and papyrus frameworks.
- Add new interface StateMachineModelFactory which is
a central point of building machines models outside
of a normal annotation/build classes. What this mean is
a hook to config model so that machine can be defined
via a model factory, instead of writing config based on
normal adapter callbacks.
- Integrate model config into an annotation model so that
you can still use normal adapters but point those to
model factory classes, which then allows external hooks
for machine configuration.
- New spring-statemachine-uml package which supports
eclipse uml2/emf frameworks to define a machine config.
- Relates to #193
- New module spring-statemachine-cluster which is
based on spring-cloud-cluster to provide leader
election.
- Ensemble now has a concept of a leader if implementation
supports it.
- New DistributedLeaderAction can use leader info to execute
action only on a leader.
- Tweak web sample with these new concepts.
- Fixes#176
- Framework to 4.2.4
- For tests, boot to 1.3.1 and embedded tomcat to 8.0.30
- Polish and re-organise gradle files
- Can now run sample boot apps in sts due to mix of
previously sts getting older tomcat version.
- Add new StateMachineContextRepository interface.
- Add new redis module having persisting support
for StateMachineContext.
- Extract kryo serializers into a new kryo module which
is then shared with zookeeper and redis modules.
- We'll add redis related tests later when we figure out
a correct pattern for integration tests.
- Fixes#110
- Add tweaks to DisposableBean.destroy() which integrates
into a lifecycle and properly closes a machine if only
destroy() is called which is a case when `session` scoped
bean is destroyed when http session is invalidated.
- Tests in SessionScopedAnnotationTests and
SessionScopedManualTests for both builder and
annotation config.
- Fixes#112
- This is a web based distributed zookeeper state machine
sample showing how multiple Spring boot instances having
a state machine can work with a zookeeper to distribute state
handling thoughout a jvm boundaries.
- Also this example is using websocket support to have live
updates of a UI for state machine state changes.
- NOTE: not yet fully working distributed sm, this
commit is considered to be a stage 1 of further
commits on this matter.
- Preliminary concept of DistributedStateMachine,
StateMachineEnsemble and StateMachinePersist.
- New module spring-statemachine-zookeeper order to
persist state in a distributed matter.
- Refactoring concept of a state machine access to get
better internal access into a sm via functional interfaces.
- Change build to use jdk7 and change test to rely on jdk8
order to test functional lambdas.
- new zookeeper sample demonstrating distributed concepts.
- Relates t0 #35 and #34.
- No docs until things are fully implemented.
- resolves#5
- big conceptual changes to how sub-machines are handled
order to get events working with a multi-level sub states.
- added more typing throughout few interfaces to properly
pass in state context via action axecution chain.
this type change effectively caused change to most of the
classes but not that much functional change of behaviour.
- cleaning and tidy up
