[WIP] New actor creation pipeline #2638
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
DO NOT MERGE: work in progress
This PR brings some initial work on the ideas I've started to talk about in #1675 . Esentially it's simplification of an existing actor creation pipeline: instead of ActorProducer/ActorProducerPipeline/Resolver classes we can have single
IDependencyResolver
class directly underActorSystem
itself.This also means that Akka.DI.Core is no longer needed. If user want ot setup it's own dependency resolver, he/she can set it up by calling
actorSystem.UseDependencyResolver(dependencyResolverImpl)
right after creating actor system.This implementation also supports using dependency resolver for non-actor objects i.e. persistence EventAdapters. Ideally it would be great, if we could replace all
Activator.CreateInstance
calls with it.Dependency resolver can be used for all actors not created via
Props.Create(() => new MyActor(x, y, z))
as we know, that those actors are created totally correctly without it. It will be used for other types of props i.e.: you no longer needProps.DI().Create<MyActor>()
asProps.Create<MyActor>()
will rely on dependency resolver anyway.There is also a support for partial DI application, so a situation when user may want to specify some of the arguments, while leaving the rest of them in a hands of a resolver. Example:
This will take anonymous object and by using reflection will try to match parameters provided as object properties by name and type (name and type must be an exact match at this point). Missing constructor parameters will be supplied from resolver.
Only regression at this point is that components created by resolver are not allowed to contain null values, as this is the way DR gets informed that it's expected to fill the missing parameter.
TODOs
UseDependencyResolver
will be used to change it.