Any ideas how to avoid container.Verify(); problems?

[thomaslazar]

Hi there.

Just wanted to ask if someone has a clue on how to avoid errors on container.Verify().

When you verify the container it tries to create all registrations. Which isn't really good for actor classes as one would know. Not that it actually is a problem, but it throws annoying error messages like "no active Context or ActorSystem or whatnot".

[Danthar]

Don't do anything with SimpleInjector. So sry no idea. But if you know a fix for this problem. I'd happily take PR's.

[to11mtm]

I've come up with a bit of a solution that provides some value with .Verify() and SimpleInjector:

//Register -already created- ActorSystem into SimpleInjector as a singleton
//New up DependencyResolver here

var blank =(ActorCell) System.Runtime.Serialization.FormatterServices.GetUninitializedObject(typeof(ActorCell));
Akka.Actor.Internal.InternalCurrentActorCellKeeper.Current = blank;
//Call Container.Verify;
Akka.Actor.Internal.InternalCurrentActorCellKeeper.Current = null;

Some notes, @dotnetjunkie would possibly be able to provide some guidance in places:

• TBF you may or may not actually need to register the Actorsystem. I know I did for my use case. But if you do you really should pass it in rather than try to have it created via a factor; for some reason even if I tried to register it as a singleton with a Factory it seemed like it would try to double-create when I grabbed it out of the container later.

• I don't know what undefined behavior I may or may not be invoking with this pattern. I typically hide it behind a conditional flag such that it never runs in production. One behavior I -do- know is that of course the actorsystem -is- starting. If actors have unusual behavior in their constructors, they -will- be triggered (Some of the logging actor plugins come to mind here). If your configuration is auto-joining a cluster, it -will- start to auto join. Again, this was a non issue for our setup but YMMV.

• I think some of the challenge with what I mentioned above is the IDependencyResolver abstraction: The behavior of .Create<TActor>() and .Create(Type actorType) appears to be dependent on ActorSystem being present in the class in all DI Plugins I have seen.

[dotnetjunkie]

Don't do anything with SimpleInjector. So sry no idea. But if you know a fix for this problem. I'd happily take PR's.

This problem is not limited to Simple Injector. Other DI Containers do up-front verification (although most do not include diagnostics OOTB). One of those DI Containers that might cause you to run into problems is Microsoft.Extensions.DependencyInjection v3.0. It allows iterating all registrations and instantiating them all (using ValidateOnBuild = true).

The issue raised here, unfortunately, lacks enough details for me to see what's going on, but it could be caused by the injection on some runtime data that might not be available during verification.

If Akka injects runtime data objects into constructors of consumers, it means it applies the Closure Composition Model. That's not a bad thing per se, but does force require special care to allow object graphs to be verified. For instance, a practice you can apply when using Simple Injector is make the registration for the runtime data with a delegate that checks if the container is currently in verification (using Container.IsVerifying), and if so, return a dummy instance.