Fix some typos

docs/src/reference/asciidoc/appendix.adoc

@@ -86,7 +86,7 @@ state changes.
 
 *Initial State*::
 A special state in which the state machine starts. Initial state is
-always bound to a particulal state machine or a region. A state
+always bound to a particular state machine or a region. A state
 machine with a multiple regions may have a multiple initial states.
 
 *End State*::
@@ -222,7 +222,7 @@ Guard conditions are expressions which evaluates either to *TRUE* or
 are used with actions and transitions to dynamically choose if
 particular action or transition should be executed. Aspects of guards,
 event parameters and extended state variables are simply to make state
-machine desing much more simple.
+machine design much more simple.
 
 ==== Events
 Event is the most used trigger behaviour to drive a state machine.
@@ -244,7 +244,7 @@ absence of state entry and exit actions.
 
 ===== External vs. Local Transition
 Most of the cases external and local transition are functionally
-equivalent expect in cases where transition is happening between super
+equivalent except in cases where transition is happening between super
 and sub states. Local transition doesn't cause exit and entry to
 source state if target state is a substate of a source state. Other
 way around, local transition doesn't cause exit and entry to target
@@ -257,7 +257,7 @@ with a very simplistic super and sub states.
 
 ==== Actions
 Actions are the ones which really glues state machine state changes
-with a users own code. State machine can execute action on various
+with a user's own code. State machine can execute action on various
 changes and steps in a state machine like entering or exiting a state,
 or doing a state transition.
 
@@ -286,10 +286,10 @@ machine will simply see what a super state can handle.
 ==== Regions
 Regions which are also called as orthogonal regions are usually viewed
 as exclusive OR operation applied to a states. Concept of a region in
-terms of a state machine is usually a little difficult to understang
+terms of a state machine is usually a little difficult to understand
 but things gets a little simpler with a simple example.
 
-Some of use have a full size keyboard with main keys on a left side and numeric
+Some of us have a full size keyboard with main keys on a left side and numeric
 keys on a right side. You've probably noticed that both sides really
 have their own state which you see if you press a numlock key which
 only alters behaviour of numbad itself. If you don't have a full size
@@ -300,7 +300,7 @@ operating on different state machines.
 
 It would be a little inconvenient to handle two different
 statemachines as totally separate entities because in a sense they are
-still working together in a sense. This is why orthogonal regios can
-combine together a multiple simultaneous states withing a single state
+still working together in a sense. This is why orthogonal regions can
+combine together a multiple simultaneous states within a single state
 in a state machine.
 

docs/src/reference/asciidoc/introduction.adoc

@@ -49,7 +49,7 @@ ask developer to go home when things are starting to look too complex.
 
 == Usage Scenarios
 
-Project is a good candiate to use state machine if:
+Project is a good candidate to use state machine if:
 
 * Application or part of its structure can be represented as states.
 * You want to split complex logic into smaller manageable tasks.
@@ -61,7 +61,7 @@ You are already trying to implement a state machine if:
 * Use of boolean flags or enums to model situations.
 * Having variables which only have meaning for some part of your
   application lifecycle.
-* Looping throught if/else structure and checking if particular flag or
+* Looping through if/else structure and checking if particular flag or
   enum is set and then making further exceptions what to do when certain
   combination of your flags and enums exists or doesn't exist together.
 

docs/src/reference/asciidoc/sm-examples.adoc

@@ -24,7 +24,7 @@ projects `build/libs` directory.
 
 Turnstile is a simple device which gives you an access if payment is
 made and is a very simple to model using a state machine. In its
-simples form there are only two states, `LOCKED` and `UNLOCKED`. Two
+simplest form there are only two states, `LOCKED` and `UNLOCKED`. Two
 events, `COIN` and `PUSH` can happen if you try to go through it or
 you make a payment.
 
@@ -136,7 +136,7 @@ include::samples/demo/showcase/Application.java[tags=snippetD]
 include::samples/demo/showcase/Application.java[tags=snippetE]
 ----
 
-Lets go throught what this state machine do when it's executed and we
+Lets go through what this state machine do when it's executed and we
 send various event to it.
 
 [source,text]
@@ -199,13 +199,13 @@ What happens in above sample:
   unable to handle event _H_ due to guard condition, its parent is
   checked next. This guarantees that while on state _S2_, `foo` flag
   is always flipped around. However in state _S1_ event _H_ always
-  match to its dummy transtion without guard or action, not never
+  match to its dummy transition without guard or action, not never
   happens.
 
 == CD Player
 CD Player is a sample which resembles better use case of most of use have
 used in a real world. CD Player itself is a really simple entity where
-user can open a deck, inser or change a disk, then drive player
+user can open a deck, insert or change a disk, then drive player
 functionality by pressing various buttons like _eject_, _play_,
 _stop_, _pause_, _rewind_ and _backward_.
 
@@ -217,7 +217,7 @@ things actually get a bit convoluted.
 You've probably noticed that if your deck is open and you press play,
 deck will close and a song will start to play if CD was inserted in
 a first place. In a sense when deck is open you first need to close
-it and then try to start playing if cd is actually instered. Hopefully
+it and then try to start playing if cd is actually inserted. Hopefully
 you have now realised that a simple CD Player is not anymore so simple.
 Sure you can wrap all this with a simple class with few boolean variables
 and probably few nested if/else clauses, that will do the job, but what
@@ -226,7 +226,7 @@ really want to keep adding more flags and if/else clauses.
 
 image::images/statechart3.png[width=500]
 
-Lets go throught how this sample and its state machine is designed and
+Lets go through how this sample and its state machine is designed and
 how those two interacts with each other. Below three config sections
 are used withing a _EnumStateMachineConfigurerAdapter_.
 

docs/src/reference/asciidoc/sm.adoc

@@ -55,11 +55,11 @@ include::samples/DocsConfigurationSampleTests.java[tags=snippetB]
 === Configuring Regions
 
 There are no special configuration methods to mark a collection of
-states to be part of a orthogonal state. To put it simple, orthogonal
+states to be part of an orthogonal state. To put it simple, orthogonal
 state is created when same hierarchical state machine has multiple set
-of states each having a initial state. Because a individual state
-machine can only have one initial state, multiple initial states mush
-mean that a specific state mush have multiple independent regions.
+of states each having a initial state. Because an individual state
+machine can only have one initial state, multiple initial states must
+mean that a specific state must have multiple independent regions.
 
 [source,java,indent=0]
 ----
@@ -178,7 +178,7 @@ include::samples/DocsConfigurationSampleTests.java[tags=snippetT]
 Join needs to be defined in both states and transitions to work
 properly. Mark particular state as choice state by using `join()`
 method. This state doesn't need to match either source states or
-target state in a transition configuretion.
+target state in a transition configuration.
 
 Select one target state where transition goes when all source states
 has been joined. If you use state hosting regions as source, end
@@ -225,7 +225,7 @@ include::samples/DocsConfigurationSampleTests.java[tags=snippetL]
 Current limitation of factory is that all actions and guard it is
 associating with created state machine will share a same instances.
 This means that from your actions and guard you will need to
-specifially handle a case that same bean will be called by a different
+specifically handle a case that same bean will be called by a different
 state machines. This limitation is something which will be resolved in
 future releases.
 
@@ -302,12 +302,12 @@ expression as an argument.
 _StateContext_ is a domain object representing a current status of a
 state machine within a transition or an action. Context gives an
 access to a various information like event, message headers, extended
-state variables, current trasition and a top-level state machine in
-case there is a need to send events to a futher processing.
+state variables, current transition and a top-level state machine in
+case there is a need to send events to a further processing.
 
 [[sm-triggers]]
 == Triggering Transitions
-Driving a statemachine is done via transitions which are triggerred
+Driving a statemachine is done via transitions which are triggered
 by triggers. Currently supported triggers are _EventTrigger_ and
 _TimerTrigger_.
 
@@ -408,7 +408,7 @@ either listening its events or using actions with states and
 transitions. Time to time this approach would be too limited and
 verbose to create interaction with the application a state machine is
 working with. For this specific use case we have made a spring style
-context intergration which easily attach state machine functionality
+context integration which easily attach state machine functionality
 into your beans.
 
 === Annotation Support