Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
thomaslazar opened this issue Dec 10, 2019 · 3 comments
Open

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

thomaslazar opened this issue Dec 10, 2019 · 3 comments

Comments

@thomaslazar
Copy link

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
Copy link
Contributor

Danthar commented Feb 4, 2020

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
Copy link

to11mtm commented Jun 20, 2020

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

4 participants