- PropertyMaster is the only place in Akka which calls
ClassLoader.getClass (apart from kernel, which might be special)
- all PropertyMaster methods (there are only three) take a ClassManifest
of what is to be constructed, and they verify that the obtained object
is actually compatible with the required type
Other stuff:
- noticed that I had forgotten to change to ExtendedActorSystem when
constructing Extensions by ExtensionKey (damn you, reflection!)
- moved Serializer.currentSystem into JavaSerializer, because that’s the
only one needing it (it’s only used in readResolve() methods)
- Serializers are constructed now with one-arg constructor taking
ExtendedActorSystem (if that exists, otherwise no-arg as before), to
allow JavaSerializer to do its magic; possibly necessary for others as
well
- Removed all Option[ClassLoader] signatures
- made it so that the ActorSystem will try context class loader, then
the class loader which loaded the class actually calling into
ActorSystem.apply, then the loader which loaded ActorSystemImpl
- for the second of the above I added a (reflectively accessed hopefully
safe) facility for getting caller Class[_] objects by using
sun.reflect.Reflection; this is optional an defaults to None, e.g. on
Android, which means that getting the caller’s classloader is done on
a best effort basis (there’s nothing we can do because a StackTrace
does not contain actual Class[_] objects).
- refactored DurableMailbox to contain the owner val and use that
instead of declaring that in all subclasses
- re-label Client/Server to Inbound/Outbound for netty settings
description
- move to just using exactly one class loader for all reflective
activities of the ActorSystem, which is either the context class
loader or the one which loaded the ActorSystem’s class; document that
putting Akka on boot class path will not work
- be more careful with initializing the Client- and ServerBootstrap
- rename Port to DesiredPortFromConfig to discourage misuse
- write test for NettySettings
- various small fixes
- it is customary to use class name for categorizing logs, hence we
should support it; class is taken from logSource.getClass
- update SLF4J module to use logClass as category and set logSource in
MDC "akkaSource"
- add docs
* Changed signatures and constructor of MessageDispatcherConfigurator
* Changed Dispatchers.lookup, keep configurators instead of dispatchers
* Removed most of the Dispatchers.newX methods, newDispatcher is still there because of priority mailbox
* How should we make it easy to configure priority mailbox?
* Changed tons tests
* Documentation and ScalaDoc is not updated yet
* Some tests in ActorModelSpec are temporary ignored due to failure
* Aligned the Java and Scala documentation for Actors
* Implemented hotswap samples in Java, and documented in same way as Scala docs
* Improved Actors (Scala) docs
* Fixed wrong preRestart and postRestart in UntypedActor
* Changed name of Dispatchers.fromConfig to newFromConfig and made it Java friendly
* Added ActorRef.ask with Timeout parameter in addition to the timeoutMillis
- create RemoteActorRef in actorFor
- simplify send/receive because Futures/Exceptions do not go over the
wire anymore
- add RemoteCommunicationSpec which uses two ActorSystems communicating
in the same JVM via TCP socket