* scala.concurrent.Future$InternalCallbackExecutor$ doesn't exist in
Scala 2.13
* also changed the fallback to use sameThreadExecutionContext since they
seems to be identical
* the one for NoMessage fails with Scala 2.13
* the origin of these tests was when Java serialization was
used for system messages, which isn't used any more
* Scala doesn't guarantee java serialization compatibility between
major versions anyway
Ref #26233
Currently Akka fails to build on sbt community build, which runs on JDK 8. Likely it will fail on Scala community build as well due to `--ignore-source-errors`.
This makes the flag conditional based on the running JDK.
It will be useful for Scala toolchain to be able to validate its latest using latest Akka if possible.
* To avoid ClassCastException of TimerMsg if TimerMsg is already enqueued
in mailbox and there is a restart with intiial behavior that is not using withTimers
* let ActorAdapter be responsible of intercepting TimerMsg
* instead of trying to keep the TimerInterceptor when restarting
* more conistent cancelation of timers when exception/restart
* allow combining snapshotWhen and RetentionCriteria
* RetentionCritieria unit test
* move retention and snapshot tests to separate EventSourcedBehaviorRetentionSpec
* because EventSourcedBehaviorSpec is testing too many different things
* Update Scaldoc and reference documentation
* moved it to the snapshotting page
* Remove Scala 2.11 from crossScalaVersions
* because +buildRelease doesn't work with mixed crossScalaVersions
* let's use akka.build.scalaVersion when building for 2.11
* aggregatedProjects adjusted depending on akka.build.scalaVersion is 2.11 or not,
there excluding/including the -typed modules
* update travis to use akka.build.scalaVersion
* Effect.persist(event).thenUnstashAll().thenRun(..) can be misinterpreted
as the callback of thenRun is invoked when all unstashing has been completed,
while it is actually running the callback first and the the unstashing process
follows.
* Unstashing is a process where stashed commands are processed one-by-one
and waiting for persist effects to complete before processing next.
* Even if we would come up with a way to keep pending callbacks around during
the unstashing it would probably be complicated for user to reason about it.
Suddenly a callback is executed from an old command although several other
commands (that were stashed/unstashed) have been processed inbetween.
* This change makes the unstashAll Effect terminal, meaning that additional
effects like thenRun can't be added after unstashAll.
* ReplyEffect is also terminal, which makes sense since it's supposed to be
returned effect. It must still be possible to combine with thenUnstashAll,
thenReply.thenUnstashAll.
* include state in EventSourcedBehavior.receiveSignal, #26574
* because state type can't be inferred in RecoveryCompleted
* and probably useful to always have access to the state for the signals
* PartialFunction with (state,signal) tuple
* improve how to handle exceptions from signals
