DOC: Replace all akka.conf references. Fixes #1469

* Let us use :ref:`configuration` in all places to refer to the configuration.

akka-docs/scala/dispatchers.rst

@@ -120,17 +120,8 @@ should have, as shown above. This defines the number of messages for a specific
 Actor the dispatcher should process in one single sweep; in other words, the
 dispatcher will bunch up to ``throughput`` message invocations together when
 having elected an actor to run.  Setting this to a higher number will increase
-throughput but lower fairness, and vice versa. If you don't specify it
-explicitly then it uses the default value defined in the 'akka.conf'
-configuration file:
-
-.. code-block:: ruby
-
-  actor {
-    throughput = 5
-  }
-
-If you don't define a the 'throughput' option in the configuration file then the default value of '5' will be used.
+throughput but lower fairness, and vice versa. If you don't specify it explicitly 
+then it uses the value (5) defined for ``default-dispatcher`` in the :ref:`configuration`.
 
 Browse the `ScalaDoc <scaladoc>`_ or look at the code for all the options available.
 

akka-docs/scala/fsm.rst

@@ -498,7 +498,7 @@ and in the following.
 Event Tracing
 -------------
 
-The setting ``akka.actor.debug.fsm`` in ``akka.conf`` enables logging of an
+The setting ``akka.actor.debug.fsm`` in `:ref:`configuration` enables logging of an
 event trace by :class:`LoggingFSM` instances::
 
   class MyFSM extends Actor with LoggingFSM[X, Z] {

akka-docs/scala/futures.rst

@@ -244,7 +244,7 @@ In this example, if an ``ArithmeticException`` was thrown while the ``Actor`` pr
 Timeouts
 --------
 
-Waiting forever for a ``Future`` to be completed can be dangerous. It could cause your program to block indefinitly or produce a memory leak. ``Future`` has support for a timeout already builtin with a default of 5 seconds (taken from 'akka.conf'). A timeout is an instance of ``akka.actor.Timeout`` which contains an ``akka.util.Duration``. A ``Duration`` can be finite, which needs a length and unit type, or infinite. An infinite ``Timeout`` can be dangerous since it will never actually expire.
+Waiting forever for a ``Future`` to be completed can be dangerous. It could cause your program to block indefinitly or produce a memory leak. ``Future`` has support for a timeout already builtin with a default of 5 seconds (taken from :ref:`configuration`). A timeout is an instance of ``akka.actor.Timeout`` which contains an ``akka.util.Duration``. A ``Duration`` can be finite, which needs a length and unit type, or infinite. An infinite ``Timeout`` can be dangerous since it will never actually expire.
 
 A different ``Timeout`` can be supplied either explicitly or implicitly when a ``Future`` is created. An implicit ``Timeout`` has the benefit of being usable by a for-comprehension as well as being picked up by any methods looking for an implicit ``Timeout``, while an explicit ``Timeout`` can be used in a more controlled manner.
 

akka-docs/scala/stm.rst

@@ -271,23 +271,7 @@ The following settings are possible on a TransactionFactory:
 - ``propagation`` - For controlling how nested transactions behave.
 - ``traceLevel`` - Transaction trace level.
 
-You can also specify the default values for some of these options in ``akka.conf``. Here they are with their default values:
-
-::
-
-  stm {
-    fair             = on     # Should global transactions be fair or non-fair (non fair yield better performance)
-    max-retries      = 1000
-    timeout          = 5      # Default timeout for blocking transactions and transaction set (in unit defined by
-                              #     the time-unit property)
-    write-skew       = true
-    blocking-allowed = false
-    interruptible    = false
-    speculative      = true
-    quick-release    = true
-    propagation      = "requires"
-    trace-level      = "none"
-  }
+You can also specify the default values for some of these options in the :ref:`configuration`.
 
 You can also determine at which level a transaction factory is shared or not shared, which affects the way in which the STM can optimise transactions.
 

akka-docs/scala/testing.rst

@@ -457,7 +457,7 @@ Accounting for Slow Test Systems
 The tight timeouts you use during testing on your lightning-fast notebook will
 invariably lead to spurious test failures on the heavily loaded Jenkins server
 (or similar). To account for this situation, all maximum durations are
-internally scaled by a factor taken from ``akka.conf``,
+internally scaled by a factor taken from the :ref:`configuration`,
 ``akka.test.timefactor``, which defaults to 1.
 
 Resolving Conflicts with Implicit ActorRef
@@ -716,7 +716,7 @@ options:
 
 * *Logging of message invocations on certain actors*
 
-  This is enabled by a setting in ``akka.conf`` — namely
+  This is enabled by a setting in the :ref:`configuration` — namely
   ``akka.actor.debug.receive`` — which enables the :meth:`loggable`
   statement to be applied to an actor’s :meth:`receive` function::
 
@@ -728,7 +728,7 @@ options:
   The first argument to :meth:`LoggingReceive` defines the source to be used in the
   logging events, which should be the current actor.
 
-  If the abovementioned setting is not given in ``akka.conf``, this method will
+  If the abovementioned setting is not given in the :ref:`configuration`, this method will
   pass through the given :class:`Receive` function unmodified, meaning that
   there is no runtime cost unless actually enabled.
 

akka-docs/scala/typed-actors.rst

@@ -178,7 +178,7 @@ Messages and immutability
 
 **IMPORTANT**: Messages can be any kind of object but have to be immutable (there is a workaround, see next section). Java or Scala can’t enforce immutability (yet) so this has to be by convention. Primitives like String, int, Long are always immutable. Apart from these you have to create your own immutable objects to send as messages. If you pass on a reference to an instance that is mutable then this instance can be modified concurrently by two different Typed Actors and the Actor model is broken leaving you with NO guarantees and most likely corrupt data.
 
-Akka can help you in this regard. It allows you to turn on an option for serializing all messages, e.g. all parameters to the Typed Actor effectively making a deep clone/copy of the parameters. This will make sending mutable messages completely safe. This option is turned on in the ‘$AKKA_HOME/config/akka.conf’ config file like this:
+Akka can help you in this regard. It allows you to turn on an option for serializing all messages, e.g. all parameters to the Typed Actor effectively making a deep clone/copy of the parameters. This will make sending mutable messages completely safe. This option is turned on in the :ref:`configuration` file like this:
 
 .. code-block:: ruby