Fixed a typo in Documentation chapter 10
Merge pull request #125 from andreassimon/patch-1

Fixed a typo in Documentation chapter 10
Fixed custom ParameterResolverFactory support in annotated aggregates

The ParameterResolverFactory can now be attached to the Unit of Work. When an
aggregate is created outside the scope of an AggregateFactory, the aggregate
tries to pick up the PRF from the UoW. If not present, it will resort to the
default implementation.

Issue #AXON-265 Fixed
Fix for Axon-263: Saga managers don't accept multiple base packages for scanning. The base-package value is now split on comma before processing.
Adapted unit tests for multi-package support in saga manager

Issue #AXON-263 Fixed
Fixed issue where classpath scanning for Saga reveils no instances

The SagaManager would throw an exception when initialized without any concrete
instances.

Issue #AXON-264 Fixed
AuditLogger interface issue

The interface declares an Object as type of message. However, at runtime the
command is always an instance of CommandMessage. The interface has been
modified.

Issue #AXON-251 Fixed
Aggregate state properly reset on commitEvents()

There is a possible issue when apply invocations are nested and there
 is an aggregate cache in place. The cached aggregate could be kept
 in an inconsistent state.

Issue #AXON-268 Fixed
The DisruptorCommandBus can now handle commands not affecting aggregates

When no aggregate is loaded, nor added to the repository, the
DisruptorCommandBus would fail with a NullPointerException. It has
now been fixed to cope with this situation as expected.

Issue #AXON-267 Fixed
Added support for @CommandHandler on collection of entities

It is now possible to forward commands to Entities stored in a fields extending
Collection. The @CommandHandlerCollection annotation indicates the properties
with identifiers that must match for a specific entity to be a candidate.

Issue #AXON-241 Fixed
Fixed timing issue of afterReplay() when replaying on async cluster

The afterReplay() method was invoked after all events had been sent to the
wrapped cluster. If this cluster processes events asynchronously, it is not
unlikely that the afterReplay() method is invoked before all events have been
handled completely.
Currently, the ReplayingCluster will wait for the last event to have been
processed, before invoking the afterReplay() method. The timeout can be
configured by providing meta data on the cluster.

Issue #AXON-269 Fixed