This should be safe for a rolling update between Akka 2.5.x and 2.6.0
also if additional-bindings were disabled in 2.5.x because:
* if 2.6.0 sends one of those the serializer (akka-misc) exists in 2.5.x
so deserialization will work via the serializerId
* if 2.5.x sends one of those with java serialization it can be
deserialized in 2.6.0 since the java serializer exists
(disabling java serialization by default is another ticket)
* historical problems with serialization of remote Deploy messages
in Akka 2.4.x should be gone now
* kept part of OrElseSpec to illustrate composition with
functions or partial functions
* added an experiment with and interceptor that
delegates to behaviors
* Always be explicit about what message types an interceptor can handle, to avoid
ClassCastException if another message type is passing. That may happen when
the inner behavior understands other messages than it says in it's declared
behavior type by using narrow. EventSourcedBehaviorImpl is an example.
* Minimized failing tests
* Supervision interceptor is of type Any since failures of all messages must be
handled
* Changed PoisonPillInterceptor to only intercept signals
* rename type params to Outer and Inner
* separate BehaviorSignalInterceptor
* which only intercepts signals and messages bypass, e.g. PoisonPillInterceptor
* also made aroundSignal optional to override in BehaviorInterceptor
* Add test for interceptors combined with EventSourcedBehavior
* ClassTag not needed for LogMessagesInterceptor
* since it can handle Any
* test supervision of different message type
* clarify low level
* docs for interceptMessageClass param and ClassTag
* remove O type parameter in supervision
* remove extra setup for RestartSupervisor, already factory
* mention in migration guide
* Re-write InputStreamPublisher as a GraphStage
* Deprecate IOResult.failure and introduce IOOperationIncompleteException
After some dicussion with @johanandren, @raboof and @2m about the
confusion of the materialised value of the IO streams to complete
even if there is an exception (with the exception in the IOResult)
this now changes it to:
* Deprecate failure in IOResult so it is always set to Success(Done)
* Stop using AbrubtIOTerminationException as the inner IOResult also
contains an exception causing confusion
* readers tend to try what is at the top of the page
and given the limitations of BehaviorTestKit we
should show the full featured asyncronous TestKit first
* mention test framework integration earlier
* better example in the test framework section
* Reduce boilerplate for interaction with Typed Replicator #27116
* By introducing a message adapter "helper" that is specific the Replicator
* Specific methods for askUpdate, askGet and askDelete, subscribe, unsubscribe
* add thread safetey warnings
* DistributedData.withReplicatorMessageAdapter for creating the ReplicatorMessageAdapter
* Send a `start` message to the first actor
Otherwise, only the actor system is started, but none of the actors.
* Send a `start` message to the first actor
Otherwise, only the actor system is started, but none of the actors.
According to this: https://stackoverflow.com/a/56154292/3715185, adding an id to the execution configuration can help to keep Maven from generating erroneous tags in the effective pom, such as adding a `<resource>` tag to the `ManifestResourceTransformer`.
This moves the Maven documentation from the 'configuration' section to the
'deploy' section, and adds documentation for Gradle.
A further improvement would be to split up the current 'deploy' docs and
separate 'bundling' from 'deploying', but that is for a future PR.
* move AccountExample to Sharding, to be able to test with EntityRef etc
* add tests for AccountExample
* for javadsl there is a problem
* explicity replyTo type solves javadsl issue
* use EventSourcedEntity.withEnforcedReplies
* try replyTo with super type AccountCommandReply
* Reply <: AccountCommandReply
* replace lambda with method (constructor) reference
* No clear advantage over CBOR
* One less choice for users
* CBOR seems to have a stronger specification and therefore potential
for wider adoption
* Performance of CBOR is equals to Smile
* Smile can be slightly more compact
(I think it does more to reduce repeated field names),
but that might be better to solve with good compression
