Updated documentation

documentation/src/main/docbook/en-US/reference-guide/3-command-handling.xml

@@ -324,7 +324,7 @@ MyGateway myGateway = factory.createInstance(MyGateway.class);</programlisting>
                             aggregate is created, all commands will be executed exactly in the order
                             they were dispatched. To ensure the order, use a callback on the
                             creating command to wait for the aggregate being created. It shouldn't
-                            take more than a few milliseconds. </para>
+                            take more than a few milliseconds.</para>
                     </listitem>
                 </itemizedlist></para>
             <simplesect>
@@ -773,6 +773,39 @@ public class MyEntity extends AbstractAnnotatedEntity { // extends not strictly
                                 <code>@CommandHandlingMember</code> annotated field is inspected for
                                 <code>@CommandHandler</code> methods.</para>
                     </note></para>
+                <para>Since version 2.4, it is also possible to annotate Collections of entities
+                    with <code>@CommandHandlingMemberCollection</code> and Maps with
+                        <code>@CommandHandlingMemberMap</code>. In the latter case, the values of
+                    the map must contain the entities, while the key contains a value that is used
+                    as their reference.</para>
+                <para>The <code>@CommandHandlingMemberCollection</code> annotation takes two
+                    mandatory properties: <code>entityId</code> and
+                        <code>commandTargetProperty</code>. Both are references to accessor methods
+                    that provide the values necessary for Axon to figure out which entity to forward
+                    the command to. The <code>entityId</code> property is used to identify the
+                    property on the aggregate, while <code>commandTargetProperty</code> identifies
+                    the property on the incoming command. If the returned values are
+                        <code>equals()</code> for a command/entity combination, the command is
+                    forwarded to that specific entity. On its turn, the entity may have other
+                    annotated fields to forward the command further.</para>
+                <para>The <code>@CommandHandlingMemberMap</code> is similar to the previous
+                    annotation, except that it only has the <code>commandTargetProperty</code>
+                    property. It identifies the property on the command that returns the value to
+                    use as a key for the Map. The entity returned from the map by that key receives
+                    the command.</para>
+                <para>If no Entity can be found in the annotated Collection or Map, Axon throws an
+                    IllegalStateException; apparently, the aggregate is not capable of processing
+                    that command at that point in time.</para>
+                <para>
+                    <note>
+                        <para>The field declaration for both the Collection or Map should contain
+                            proper generics to allow Axon to identify the type of Entity contained
+                            in the Collection or Map. If it is not possible to add the generics in
+                            the declaration (e.g. because you're using a custom implementation which
+                            already defines generic types), you must specify the type of entity used
+                            in the <code>entityType</code> property on the annotation.</para>
+                    </note>
+                </para>
             </simplesect>
         </sect2>
     </sect1>

documentation/src/main/docbook/en-US/reference-guide/5-repositories-and-event-stores.xml

@@ -470,7 +470,9 @@
                     <code>EventSqlSchema</code> is responsible for creating the correct
                     <code>PreparedStatement</code>s for those. When you need to change a query that
                 is executed against the database, it will usually suffice to override a single
-                method in the <code>GenericEventSqlSchema</code>.</para>
+                method in the <code>GenericEventSqlSchema</code>. The is, for example, a
+                    <code>PostgresEventSqlSchema</code> implementaion for use with a PostgreSQL
+                database.</para>
             <warning>
                 <title>Timestamps and time zones</title>
                 <para>By default, Axon stores time stamps in the system timezone. However, many
@@ -509,6 +511,26 @@
                 the collections to store the Events in, and you're set to go. For production
                 environments, you may want to double check the indexes on your collections.</para>
         </sect2>
+        <sect2>
+            <title>Event Store Utilities</title>
+            <para>Axon provides a number of wrappers for Event Stores that may be useful in certain
+                circumstances. For example, an environment may replay events up to a certain moment
+                in time, in order to reproduce the state of the application at that moment.</para>
+            <para>The <code>TimestampCutoffReadonlyEventStore</code> is, as the name suggests, a
+                read-only event store that only returns events older than a specific time. This
+                allows you to reproduce state of an application at a specific time. This class is a
+                wrapper around another event store (e.g. the one used in production).</para>
+            <para>The <code>SequenceEventStore</code> is a wrapper around two other Event Stores.
+                When reading, it returns the events from both event stores. Appended events are only
+                appended to the second event store. This is useful in cases where two different
+                implementations of Event Stores are used for performance reasons, for example. The
+                first would be a larger, but slower event store, while the second is optimized for
+                quick reading and writing.</para>
+            <para>There is also an Event Store implementation that keeps te stored events in memory:
+                the <code>VolatileEventStore</code>. While it probably outperforms any other event
+                store out there, it is not really meant for long-term production use. However, it is
+                very useful in short-lived tools or tests that require an event store.</para>
+        </sect2>
         <sect2>
             <title>Implementing your own event store</title>
             <para>If you have specific requirements for an event store, it is quite easy to

documentation/src/main/docbook/en-US/reference-guide/7-sagas.xml

@@ -513,7 +513,8 @@
                     is an interface that defines all the operations the repository needs to perform
                     on the underlying database. It allows you to customize the SQL statement
                     executed for each one of them. The default is the
-                        <code>GenericSagaSqlSchema</code>.</para>
+                        <code>GenericSagaSqlSchema</code>. Other implementations available are
+                        <code>PostgresSagaSqlSchema</code> and <code>HsqlSagaSchema</code>.</para>
             </simplesect>
             <simplesect>
                 <title><code>MongoSagaRepository</code></title>