Small tweaks to docs

Getting a couple of small tweaks out of the way
This commit is contained in:
Arnout Engelen 2017-04-24 15:52:14 +02:00
parent e495408627
commit f447f8e73f
8 changed files with 44 additions and 32 deletions

View file

@ -4,7 +4,6 @@
package jdocs.actor;
//#imports
import akka.actor.TypedActor;
import akka.actor.*;
import akka.japi.*;
@ -25,7 +24,6 @@ import akka.routing.RoundRobinGroup;
import org.junit.Test;
import static org.junit.Assert.assertEquals;
//#imports
public class TypedActorDocTest extends AbstractJavaTest {
Object someReference = null;
ActorSystem system = null;
@ -198,7 +196,7 @@ public class TypedActorDocTest extends AbstractJavaTest {
}
}
//#typed-router-types-1
//#typed-router-types
interface HasName {
String name();
}

View file

@ -39,12 +39,9 @@ import static akka.dispatch.Futures.reduce;
//#imports6
//#imports7
//#imports7
//#imports8
import static akka.pattern.Patterns.after;
import java.util.Arrays;
//#imports8
//#imports7
import java.util.ArrayList;
import java.util.List;

View file

@ -22,7 +22,7 @@ it will use its default dispatcher as the ``ExecutionContext``, or you can use t
by the ``ExecutionContexts`` class to wrap ``Executors`` and ``ExecutorServices``, or even create your own.
.. includecode:: code/jdocs/future/FutureDocTest.java
:include: imports1,imports7
:include: imports1
.. includecode:: code/jdocs/future/FutureDocTest.java
:include: diy-execution-context
@ -256,7 +256,7 @@ After
``akka.pattern.Patterns.after`` makes it easy to complete a ``Future`` with a value or exception after a timeout.
.. includecode:: code/jdocs/future/FutureDocTest.java
:include: imports8
:include: imports7
.. includecode:: code/jdocs/future/FutureDocTest.java
:include: after

View file

@ -291,7 +291,7 @@ of the command for which this ``deferAsync`` handler was called.
You can also call ``deferAsync`` with ``persist``.
.. includecode:: code/docs/persistence/LambdaPersistenceDocTest.java#defer-with-persist
.. includecode:: code/jdocs/persistence/LambdaPersistenceDocTest.java#defer-with-persist
.. warning::
The callback will not be invoked if the actor is restarted (or stopped) in between the call to

View file

@ -249,7 +249,7 @@ with message flows:
* :meth:`public <T> List<T> receiveWhile(Duration max, Duration idle, Int messages, Function<Object, T> f)`
.. includecode:: code/docs/testkit/TestKitDocTest.java#test-receivewhile-full
.. includecode:: code/jdocs/testkit/TestKitDocTest.java#test-receivewhile-full
Collect messages as long as

View file

@ -3,6 +3,7 @@
*/
package docs.actor
//#imports
import java.lang.String.{ valueOf => println }
import akka.actor.{ ActorContext, ActorRef, TypedActor, TypedProps }
@ -11,10 +12,10 @@ import akka.testkit._
import scala.concurrent.{ Future, Await }
import scala.concurrent.duration._
//#imports
//Mr funny man avoids printing to stdout AND keeping docs alright
import java.lang.String.{ valueOf => println }
import akka.actor.ActorRef
//#typed-actor-iface
trait Squarer {

View file

@ -5,10 +5,10 @@
#################
Logging in Akka is not tied to a specific logging backend. By default
log messages are printed to STDOUT, but you can plug-in a SLF4J logger or
log messages are printed to STDOUT, but you can plug-in a SLF4J logger or
your own logger. Logging is performed asynchronously to ensure that logging
has minimal performance impact. Logging generally means IO and locks,
which can slow down the operations of your code if it was performed
which can slow down the operations of your code if it was performed
synchronously.
How to Log
@ -76,7 +76,7 @@ to the :ref:`event-stream-scala`.
Auxiliary logging options
-------------------------
Akka has a few configuration options for very low level debugging. These make more sense in development than in production.
Akka has a few configuration options for very low level debugging. These make more sense in development than in production.
You almost definitely need to have logging set to DEBUG to use any of the options below:
@ -269,17 +269,17 @@ Loggers
=======
Logging is performed asynchronously through an event bus. Log events are processed by an event handler actor
that receives the log events in the same order they were emitted.
that receives the log events in the same order they were emitted.
.. note::
The event handler actor does not have a bounded inbox and is run on the default dispatcher. This means
that logging extreme amounts of data may affect your application badly. This can be somewhat mitigated by
using an async logging backend though. (See :ref:`slf4j-directly-scala`)
using an async logging backend though. (See :ref:`slf4j-directly-scala`)
You can configure which event handlers are created at system start-up and listen to logging events. That is done using the
You can configure which event handlers are created at system start-up and listen to logging events. That is done using the
``loggers`` element in the :ref:`configuration`.
Here you can also define the log level. More fine grained filtering based on the log source
can be implemented in a custom ``LoggingFilter``, which can be defined in the ``logging-filter``
Here you can also define the log level. More fine grained filtering based on the log source
can be implemented in a custom ``LoggingFilter``, which can be defined in the ``logging-filter``
configuration property.
.. code-block:: ruby
@ -306,7 +306,7 @@ Logging to stdout during startup and shutdown
When the actor system is starting up and shutting down the configured ``loggers`` are not used.
Instead log messages are printed to stdout (System.out). The default log level for this
stdout logger is ``WARNING`` and it can be silenced completely by setting
stdout logger is ``WARNING`` and it can be silenced completely by setting
``akka.stdout-loglevel=OFF``.
.. _slf4j-scala:
@ -480,13 +480,13 @@ some malicious activity and mark them with a ``SECURITY`` tag, and in your appen
trigger emails and other notifications immediately.
Markers are available through the LoggingAdapters, when obtained via ``Logging.withMarker``.
The first argument passed into all log calls then should be a ``akka.event.LogMarker``.
The first argument passed into all log calls then should be a ``akka.event.LogMarker``.
The slf4j bridge provided by akka in ``akka-slf4j`` will automatically pick up this marker value and make it available to SLF4J.
For example you could use it like this::
<pattern>%date{ISO8601} [%marker][%level] [%msg]%n</pattern>
A more advanced (including most Akka added information) example pattern would be::
<pattern>%date{ISO8601} level=[%level] marker=[%marker] logger=[%logger] akkaSource=[%X{akkaSource}] sourceActorSystem=[%X{sourceActorSystem}] sourceThread=[%X{sourceThread}] mdc=[ticket-#%X{ticketNumber}: %X{ticketDesc}] - msg=[%msg]%n----%n</pattern>
@ -500,7 +500,7 @@ Akka includes a logger for `java.util.logging <https://docs.oracle.com/javase/8/
You need to enable the ``akka.event.jul.JavaLogger`` in the ``loggers`` element in
the :ref:`configuration`. Here you can also define the log level of the event bus.
More fine grained log levels can be defined in the configuration of the logging backend.
More fine grained log levels can be defined in the configuration of the logging backend.
You should also define ``akka.event.jul.JavaLoggingFilter`` in
the ``logging-filter`` configuration property. It will filter the log events using the backend
configuration before they are published to the event bus.

View file

@ -63,21 +63,25 @@ Creating Typed Actors
To create a Typed Actor you need to have one or more interfaces, and one implementation.
The following imports are assumed:
.. includecode:: code/docs/actor/TypedActorDocSpec.scala
:include: imports
Our example interface:
.. includecode:: code/docs/actor/TypedActorDocSpec.scala
:include: imports,typed-actor-iface
:include: typed-actor-iface
:exclude: typed-actor-iface-methods
Alright, now we've got some methods we can call, but we need to implement those in SquarerImpl.
Our example implementation of that interface:
.. includecode:: code/docs/actor/TypedActorDocSpec.scala
:include: imports,typed-actor-impl
Excellent, now we have an interface and an implementation of that interface,
and we know how to create a Typed Actor from that, so let's look at calling these methods.
:include: typed-actor-impl
:exclude: typed-actor-impl-methods
The most trivial way of creating a Typed Actor instance
of our Squarer:
of our ``Squarer``:
.. includecode:: code/docs/actor/TypedActorDocSpec.scala
:include: typed-actor-create1
@ -88,7 +92,19 @@ If you need to call a specific constructor you do it like this:
.. includecode:: code/docs/actor/TypedActorDocSpec.scala
:include: typed-actor-create2
Since you supply a Props, you can specify which dispatcher to use, what the default timeout should be used and more.
Since you supply a ``Props``, you can specify which dispatcher to use, what the default timeout should be used and more.
Now, our ``Squarer`` doesn't have any methods, so we'd better add those.
.. includecode:: code/docs/actor/TypedActorDocSpec.scala
:include: typed-actor-iface
Alright, now we've got some methods we can call, but we need to implement those in SquarerImpl.
.. includecode:: code/docs/actor/TypedActorDocSpec.scala
:include: typed-actor-impl
Excellent, now we have an interface and an implementation of that interface,
and we know how to create a Typed Actor from that, so let's look at calling these methods.
Method dispatch semantics
-------------------------