final ActorSystem system = ActorSystem.create("example");
final ActorRef persistentActor = system.actorOf(Props.create(ExamplePersistentActor.class), "persistentActor-4-java8");
Serialization serialization = SerializationExtension.get(system);
Serializer serializer = serialization.findSerializerFor(persistentActor);
Here I am able to use the serializer and it works as expected.
In 2:
final ActorSystem system = ActorSystem.create("example");
final ActorRef persistentActor = system.actorOf(Props.create(ExamplePersistentActor.class), "persistentActor-4-java8");
Serializer serializer = new JavaSerializer((ExtendedActorSystem)system);
I manually instantiate the serializer with going through the serializer.
Are there any problems with option #2? The reason I prefer it is a unserialize later in time, and can store the reference to the serializer.
Either way of using Java serialization is a pretty bad idea to be honest. It is known for its slowness and often target of attacks so not a good choice for security as well. There is a long section about this in the Akka docs Serialization • Akka Documentation as well as the akka.actor.allow-java-serialization = off option to make SerializationExtension throw if it were about to use the JavaSerializer.
We’d recommend using other tools for serialization, such as protobuf, kryo, jackson etc; with registering which classes are allowed to be deserialized etc.
Are there any problems with option #2?
That you had to cast to an internal class should be reason enough to try to avoid this style
The reason I prefer it is a unserialize later in time, and can store the reference to the serializer.
You can do the same with 1) though; keeping around the reference.
Whichever you configured for given type of message. Java being the default is a historical reason that we can’t break away from due to compatibility guarantees, though we’d love to.
We will also propose a new default which will be Jackson based, however we can’t switch the “default” since it could break peoples apps.
Note also that for some journal plugins, AFAIR MongoDB the journal may use what it thinks is best suitable, so in that example some BSON serializer for example
