Small tweaks to docs
Getting a couple of small tweaks out of the way
This commit is contained in:
parent
e495408627
commit
f447f8e73f
8 changed files with 44 additions and 32 deletions
|
|
@ -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();
|
||||
}
|
||||
|
|
|
|||
|
|
@ -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;
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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 {
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
-------------------------
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue