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

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

akka-docs/java/dispatchers.rst

@@ -19,7 +19,7 @@ Default dispatcher
 ------------------
 
 For most scenarios the default settings are the best. Here we have one single event-based dispatcher for all Actors created. The default dispatcher used is "GlobalDispatcher" which also is retrievable in ``akka.dispatch.Dispatchers.globalDispatcher``.
-The Dispatcher specified in the akka.conf as "default-dispatcher" is  as ``Dispatchers.defaultGlobalDispatcher``.
+The Dispatcher specified in the :ref:`configuration` as "default-dispatcher" is  as ``Dispatchers.defaultGlobalDispatcher``.
 
 The "GlobalDispatcher" is not configurable but will use default parameters given by Akka itself.
 
@@ -124,16 +124,13 @@ Here is an example:
      ...
   }
 
-This 'Dispatcher' allows you to define the 'throughput' it should have. This defines the number of messages for a specific Actor the dispatcher should process in one single sweep.
-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:: xml
-
-  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.
+The standard :class:`Dispatcher` allows you to define the ``throughput`` it
+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 value (5) defined for ``default-dispatcher`` in the :ref:`configuration`.
 
 Browse the :ref:`scaladoc` or look at the code for all the options available.
 

akka-docs/java/futures.rst

@@ -42,7 +42,7 @@ A common use case within Akka is to have some computation performed concurrently
                               return "Hello" + "World!";
                             }
                           });
-  String result = f.get(); //Blocks until timeout, default timeout is set in akka.conf, otherwise 5 seconds
+  String result = f.get(); //Blocks until timeout, default timeout is set in :ref:`configuration`, otherwise 5 seconds
 
 In the above code the block passed to ``future`` will be executed by the default ``Dispatcher``, with the return value of the block used to complete the ``Future`` (in this case, the result would be the string: "HelloWorld"). Unlike a ``Future`` that is returned from an ``UntypedActor``, this ``Future`` is properly typed, and we also avoid the overhead of managing an ``UntypedActor``.
 

akka-docs/java/stm.rst

@@ -182,23 +182,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 :ref:`configuration`.
 
 Transaction lifecycle listeners
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

akka-docs/java/typed-actors.rst

@@ -185,7 +185,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