-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Abstraction of ServiceProvider, Improving Akka.DependencyInjection #4814
Abstraction of ServiceProvider, Improving Akka.DependencyInjection #4814
Conversation
Thanks @SamEmber - we'll take a look at this soon |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I approve of the concept and the changes, but we need to introduce these in a more backwards-compatible way - along with the changes we're making to the ServiceProviderProps
in a separate PR.
I'll help make this happen as part of the 1.4.18 release.
/// | ||
/// The constructor is internal. Please use <see cref="Create"/> to create a new instance. | ||
/// </summary> | ||
public class DependencyResolverSetup : Setup |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be far better if we kept the ServiceProvider
setup so we can avoid breaking the public API.
/// Provides users with immediate access to the <see cref="IDependencyResolver"/> bound to | ||
/// this <see cref="ActorSystem"/>, if any. | ||
/// </summary> | ||
public sealed class DependencyResolver : IExtension |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We probably shouldn't rename the extension here, for API compatibility reasons
|
||
namespace Akka.DependencyInjection | ||
{ | ||
public interface IDependencyResolver |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I'm supportive of adding this abstraction, after discussing it with @to11mtm and reviewing some of Mark Seeman's advice here: https://blog.ploeh.dk/2014/05/19/di-friendly-framework/
We've already run into "conforming container" problems with Microsoft.Extensions.DependencyInjection 3.0 vs. 5.0 - so an abstraction like yours would be helpful for users who need to roll-forward before the library itself can.
/// | ||
/// Relies on having an active <see cref="IServiceProvider"/> implementation available | ||
/// </summary> | ||
internal class ServiceProviderProps : Props |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're going to remove this concept altogether in #4853 and replace it with an IIndirectActorProducer, similar to what we did in the original Akka.DI.Core library.
We should probably merge that PR in first once it gets submitted, then rebase this on top of it.
IDependencyResolver Resolver { get; } | ||
} | ||
|
||
public class ServiceProviderScope : IResolverScope |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fine with this abstraction too
Thanks for taking the time to look at this Aaron, these all sound like sensible changes to me. Pleased that my suggestion will be taken into account, please let me know if there is anything I can do to help out. |
Need to get this one merged and approved into |
Hey @Aaronontheweb, was this ever integrated? |
@SamEmber not yet - was up to my neck in Akka.Cluster issues over the past month. We will probably bump this to 1.4.20 |
I thought we need this too. there's no easy way to dynamically create an actor with ServiceProvider and that is my pain point writing test with ServiceProvider Also, I've been writing |
We'll give it our best shot. |
ded7717
to
7815c96
Compare
Ok, just introduced my non-breaking API implementation version of this - but someone else (@chris-sung @SamEmber included) will have to review it before we can merge it.
Pretty sure I did all of that, but need the review to verify. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Everything looks fine, I just have a little suggestion for one of the methods.
src/contrib/dependencyinjection/Akka.DependencyInjection/ServiceProviderDependencyResolver.cs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Awesome, this looks great @Aaronontheweb. Thanks for taking the time to make the required changes. |
Crap, looks like I broke the build - that's what I get for attempting to edit a PR using the Github editor :p |
No problem @SamEmber - thank you for your contribution and sorry it took me so long to get around to this. Didn't take me long to implement the changes we discussed at all, just had a full plate up until this week. |
Fantastic. Thanks for the quick resolution |
Abstraction of ServiceProvider, Improving Akka.DependencyInjection (akkadotnet#4814) * Abstraction of ServiceProvider * introduced non-breaking Akka.DependencyInjection API changes * fixed unit tests / Props bug * fixed up DelegateInjectionSpecs * Added type checking for `Props(Type type, params object[] args)` * fixed non-generic `Props()` method Co-authored-by: Aaron Stannard <aaron@petabridge.com> completed work on ActorPath parsing
* `Span<char>`-ifying ActorPath and Address parsing Abstraction of ServiceProvider, Improving Akka.DependencyInjection (#4814) * Abstraction of ServiceProvider * introduced non-breaking Akka.DependencyInjection API changes * fixed unit tests / Props bug * fixed up DelegateInjectionSpecs * Added type checking for `Props(Type type, params object[] args)` * fixed non-generic `Props()` method Co-authored-by: Aaron Stannard <aaron@petabridge.com> completed work on ActorPath parsing * restore Parse performance to ActorPath.Parse * fixed `ActorPath.ToString()`
Hi Guys,
I started using the new Akka.DependencyInjection library for MS-DI recently and I have run across a few issues that I would like to address.
The initial problem I faced was the tight coupling of the actor system DI to IServiceProvider. My team have a testing library where we substitute child actors for test probes, previously we did this via AddDependencyResolver however this has now been removed. Currently this coupling is making it very hard to achieve the previous functionality.
I propose a change to the ServiceProvider where instead of passing in an IServiceProvider we instead pass in a IDependencyResolver interface, by default this IDependencyResolver will be a SeriveProviderDependencyResolver that uses the IServiceProvider to resolve any DI dependencies. This will allow others to create their own implementations of the IDependencyResolver for testing.
I want to make it clear that I don't want to change the functionality of the current DI service resolution, its still extremely important that users manage the lifetime of their dependencies and this change will not effect that.
Secondly I have added the ability to resolve actor props from a Type param, this should make it easier to create actors dynamically.
I am very open to any feedback. I have not properly commented the code yet as I want to make sure this is a reasonable proposal from the community before I spent more time to complete this.
Thanks,
Sam