Minor text edits / fixes.

doc/src/asciidoc/ch02/iso8583.adoc

@@ -408,10 +408,10 @@ by other means (e.g., by phone) and send an advice.
 |Time|Acquirer|Issuer|Description
 |t~0~|0100 --> ||authorization request
 |t~1~|||no response
-|t~3~|0400 --> ||reverse previous authorization
-|t~4~|| <-- 0410|reverse received
-|t~5~|0120 --> ||authorization advice
-|t~6~|| <-- 0130|advice received
+|t~2~|0400 --> ||reverse previous authorization
+|t~3~|| <-- 0410|reverse received
+|t~4~|0120 --> ||authorization advice
+|t~5~|| <-- 0130|advice received
 |===============
 
 Depending on your particular implementation, you may be able to send
@@ -436,7 +436,7 @@ exchanged during an authorization request and response. See below:
 |0|MTI|0100|Authorization request
 |2|Primary Account Number|4321123443211234|
 |3|Processing Code|000000|
-|4|Amount transaction|000000012300|i.e., 123.00
+|4|Amount transaction|000000012300|e.g., 123.00
 |7|Transmission data/time|0304054133|MMYYHHMMSS
 |11|System trace audit number|001205|
 |14|Expiration date|0205|YYMM
@@ -457,7 +457,7 @@ exchanged during an authorization request and response. See below:
 |0|MTI|0110|Authorization response
 |2|Primary Account Number|4321123443211234|
 |3|Processing Code|000000|
-|4|Amount transaction|000000012300|i.e., 123.00
+|4|Amount transaction|000000012300|e.g., 123.00
 |7|Transmission data/time|0304054133|MMYYHHMMSS
 |11|System trace audit number|001205|
 |14|Expiration date|0205|YYMM

doc/src/asciidoc/ch02/jposiso.adoc

@@ -11,7 +11,7 @@ object (or an ISOMsg's subclass).
 
 The ISOMsg class uses the *Composite pattern* (see  
 Design Patterns, elements of Reusable Object-Oriented Software
-by Gamma, Helm, Johnson and Vlissides) 
+by Gamma, Helm, Johnson and Vlissides). 
 
 ISOMsg, ISOField, ISOBitMapField, ISOBinaryField and any custom field type
 that you may implement are subclasses of ISOComponent.  Let's have a look at
@@ -161,7 +161,7 @@ You use
    
 ----
 
-in order to assign a packager to a given +ISOMsg+, i.e:
+in order to assign a packager to a given +ISOMsg+, e.g.:
 
 [source,java]
 ----
@@ -607,7 +607,7 @@ channels. While you don't necesarily have to extend BaseChannel to write a
 custom channel, you'll probably find it very useful. 
 
 Depending on your wire protocol, you'll probably only need to extend
-BaseChannel and just override a few methods, i.e: 
+BaseChannel and just override a few methods, e.g.: 
 
 [source,java]
 ----

doc/src/asciidoc/ch03/configuration.adoc

@@ -47,7 +47,7 @@ We also have a very simple interface called Configurable:
 
    package org.jpos.core;
 
-   public interface Configuration {
+   public interface Configurable {
      public void setConfiguration (Configuration cfg)
         throws ConfigurationException;
    }
@@ -70,7 +70,7 @@ Should +com.mycompany.MyObject+ implement +Configurable+, Q2 would call its  +se
 providing access to the underlying +myProperty+ property.
 
 It's interesting to note that Q2 provides the ability to have array of
-properties under the same name, i.e:
+properties under the same name, e.g.:
 
 [source,xml]
 ----

doc/src/asciidoc/ch03/nameregistrar.adoc

@@ -85,7 +85,7 @@ Most components have a setName (String name) method implemented like this:
 
 
 The prefix +"mux."+ is used here in order to avoid a clash of names in the
-registrar between different classes of components using the same name  (i.e.
+registrar between different classes of components using the same name  (e.g.
 +"mux.institutionABC"+  and  +"channel.institutionABC"+). 
 
 

doc/src/asciidoc/ch05/channel_filters.adoc

@@ -92,7 +92,7 @@ order to make sure that this particular channel won't load the system with more
 The BSHFilter is one of the most useful, and one of the most abused filters. It allows you to
 run a link:http://beanshell.org[BeanShell] script that can be modified on the fly. It's extremely
 useful in situations where you need to add a field or two, or change the content of a given
-field, i.e. while testing on a tight certification window.
+field, e.g., while testing on a tight certification window.
 
 It is not intended to be used as a way to implement your business logic, BSH code is great, but
 tend to become brittle, difficult to refactor, test, you don't have IDE support, etc.
@@ -121,7 +121,7 @@ Your `bsh` file will have access to the following variables:
 * `evt`     - a LogEvent that you can use to add information to the Log
 * `cfg`     - a reference to the configuration object
 
-=== Aditional filters
+=== Additional filters
 
 Take a look at link:https://github.com/jpos/jPOS/tree/master/jpos/src/main/java/org/jpos/iso/filter[Github repository] 
 for additional samples.

doc/src/asciidoc/ch05/ssl_channels.adoc

@@ -24,7 +24,7 @@ public interface ISOServerSocketFactory {
 as well as a provider that implements both of them: +org.jpos.iso.GenericSSLSocketFactory+
 
 The ChannelAdaptor accepts an optional 'socketFactory' property in the
-channel configuration, and the QServer accepts an 'server-socket-factory'
+channel configuration, and the QServer accepts a 'server-socket-factory'
 child element.
 
 .SocketFactory configuration in a ChannelAdaptor

doc/src/asciidoc/ch06/space_interceptor.adoc

@@ -7,6 +7,6 @@ calls to a given Space without having to extend its implementation
 for full details).
 
 Using a +SpaceInterceptor+, the developer can override specific methods in
-order to perform aditional tasks.
+order to perform additional tasks.
 
 

doc/src/asciidoc/ch06/space_interface.adoc

@@ -17,7 +17,7 @@ handy methods:
 * +V rdp (K key)+
   Read an entry if it exists ('p' for 'probe').
 
-* +Vinp (K key)+
+* +V inp (K key)+
   Take an entry if it exists (again, 'p' for 'probe').
 
 * +void nrd (K key)+

doc/src/asciidoc/ch06/space_util.adoc

@@ -13,8 +13,8 @@ remove all entries under a given key
 
 * **+nextLong+**
 When used in combination with a persistent Space (such as +JDBMSpace+
-or +JESpace+), this method can be used to easilyl implement sequencers,
-i.e:
+or +JESpace+), this method can be used to easily implement sequencers,
+e.g.:
 
 [source,java]
 ------------

doc/src/asciidoc/ch07/intro.adoc

@@ -18,8 +18,8 @@ including all the components in a single [huge] XML configuration file
 was not a good idea.
 
 *  Although several QSP components supported some limited ReConfiguration, 
-   many others din't. As a result, major changes usually involved restarting 
-   the application (a very costly operation in a 24/7 system) 
+   many others didn't. As a result, major changes usually involved restarting 
+   the application (a very costly operation in a 24/7 system). 
 
 *  If for some reason, the changes involved went beyond just tweaking a 
    configuration file and required additional changes in a supporting 

doc/src/asciidoc/ch09/abort_participant.adoc

@@ -12,7 +12,7 @@ If everything goes okay and all participants return +PREPARED+, then you'll have
 no problem reaching the last set of participants. By contrast, if for some
 reason a given participant fails (e.g., imagine +FetchData+ fails), then the
 remaining participants down the list (in our example, FetchData through
-+SendRepsonse+) won't get called because the transaction manager will initiate
++SendResponse+) won't get called because the transaction manager will initiate
 the aborting procedure (which will call abort(id,context) only on the
 previously-called participants, i.e., only on ValidateMessage in our example).
 

doc/src/asciidoc/ch09/constants.adoc

@@ -7,7 +7,7 @@
 
 |ABORTED|0|
   The participant is not prepared. Transaction should be aborted.
-|PREPARE|1|
+|PREPARED|1|
   The participant is prepared to commit the transaction, provided
   all other participants down the list return PREPARED too.
 |RETRY|2|

doc/src/asciidoc/ch09/participants/send_response.adoc

@@ -26,7 +26,7 @@ It supports the following values:
 ======
 As a safety net, the `SendResponse` participant verifies that there is
 no entry in the Context under the name `TX` (typically used to store a
-JDBC/DB transaction. This is an arbitrary convention, we want to make
+JDBC/DB transaction). This is an arbitrary convention, we want to make
 sure that transactions are committed to disk before actually sending
 back responses.
 ======

doc/src/asciidoc/ch09/transaction_manager.adoc

@@ -2,7 +2,7 @@
 
 The +TransactionManager+ is a jPOS Service that monitors a Space queue waiting
 for transactions to be processed. These transactions are expected to be any
-+Serializable+ objects, but in most jPOS applications those are actually 
++Serializable+ object, but in most jPOS applications those are actually 
 +org.jpos.transaction.Context+ objects.
 
 The following image shows a typical scenario: