Child containers improvements

Question

Child containers improvements

adambajguz opened this issue a year ago · comments

While working with child containers I found three problems:

1. Child containers are not being automatically disposed with parent container.

In my opinion, when a parent contianer is disposed the usage of child contianers is pointless because disposed services may be resolved again. I'd suggest to store a list of child containers in StashboxContainer and dispose child containers when parent is disposed.

Optionally a configuration property bool DisposeChildContianersWithParentContainer can be added to ContainerConfiguration.

2. It's not possible to resolve services ignoring the parent container.

When using the StashboxContainer as a DI container for multitenant app that utilizes generic host, it's not possible to easily activate IHostedService from child containers during host startup.

~~The biggest problem is to prevent resolving of IHostedService from root/partent container - each IHostedService must be called once.~~ - EDIT 31.05.2022: this is not true, see my comment below

3. It's not possible to resolve services from parent and all its child containers.

Combining problem 1. and 2. it will be much easier in some scenarions to resolve all IHostedService services simply by calling a resolve method from root container and get all services registered in root container and its children (or just in children/predecessors).

[Flags]
public enum ResolutionBehavior 
{
    /// <summary>
    /// Indicates that services should be resolved from current and parent container.
    /// </summary>
    Default = Parent | Current,

    /// <summary>
    /// Indicates that services should be resolved from parent container of the current contianer.
    /// </summary>
    Parent = 1 << 0, // Alternatively Ancestors instead of Parent

    /// <summary>
    /// Indicates that services should be resolved from current.
    /// </summary>
    Current = 1 << 1,

    /// <summary>
    /// Indicates that services should only be resolved from child containers of the current container.
    /// </summary>
    Children = 1 << 2 // Alternatively Predecessors instead of Children
}

using (var rootContainer = new StashboxContainer())
{
    // register rootContainer services here

    var childContainer = rootContainer.CreateChildContainer();
    // register childContainer services here

    IEnumerable<IHostedService> allHostedServices = 
        rootContainer.Resolve<IEnumerable<IHostedService>>(ResolutionBehavior.Current | ResolutionBehavior.Children);

    IEnumerable<IHostedService> predecessorsHostedServices = 
        rootContainer.Resolve<IEnumerable<IHostedService>>(ResolutionBehavior.Children);


} // childContainer is disposed automatically with rootContainer

Peter Csajtai · Answer 1 · Wed May 31 2023 18:42:41 GMT+0800 (China Standard Time)

Hi @adambajguz, thank you for the suggestions!

This is a reasonable request. It could be easily achieved by accepting an attachToParent bool parameter in the CreateChildContainer() method similar to BeginScope(). This way, each child creation could signal that the created container should be disposed on the parent's disposal. If the parameter is true, the created container could be added to the tracked for dispose objects of the container's root scope.
This one is also reasonable, I see the case where it would be nice to ignore the parent container during a resolution request coming from a child.
This part is raising some questions. Jumping down to a child from a parent's request is not clear to me. If something exists in several child containers, which one should be picked starting from a parent?

Adam Bajguz · Answer 2 · Wed May 31 2023 19:12:15 GMT+0800 (China Standard Time)

Answer to 3
I was thinking more about resolving to IEnumerable<> and forgot about a scenario when a single service needs to be resolved. In single service scenario, probably the behavior should be configurable or simply forbidden.

IEnumerable<> problem
Also today I've discovered that child containers do not work as I expected. When resolving with IEnumerable<> only services from child container are returned (parent is ommited). This actually is documented:
When a dependency is missing from the child container during a resolution request, the parent will be asked to resolve the missing service. If it's found there, the parent will return only the service's registration, and the resolution request will continue with the child. Also, child registrations with the same [service type](https://z4kn4fein.github.io/stashbox/docs/getting-started/glossary#service-type--implementation-type) will override the parent's services.
but is not natural for me.

I don't know why I previously thought that when IEnumerable<> is used, services are resolved from both child and parent. This is a huge info for me that is actually problematic. Imagine having some Microsoft.Extensions.Options.IConfigureOptions<MyOptions> registered in both parent and child. I'd expect that when IConfigureOptions<MyOptions> is resolved, the instances will come from both child and parent.

Peter Csajtai · Answer 3 · Wed May 31 2023 20:47:22 GMT+0800 (China Standard Time)

Thank you for the clarification! I see your point that the services in the parent should be included in IEnumerable<> requests coming from a child.

Let me think through this. I'd like to start working on a solution including your previous points (1. & 2.). I see that you started working on a related PR, would you like to continue the work on that or rather wait for my proposal?

Adam Bajguz · Answer 4 · Wed May 31 2023 21:36:14 GMT+0800 (China Standard Time)

@z4kn4fein I started working but after today's discovery the "IEnumerable<> problem" from previous comment, I feel that I need your help. You can reuse my proposal or start from scratch :)

Adam Bajguz · Answer 5 · Wed May 31 2023 21:38:05 GMT+0800 (China Standard Time)

I see your point that the services in the parent should be included in IEnumerable<> requests coming from a child. I think this should be configurable in case someone needs the old behavior.

Peter Csajtai · Answer 6 · Wed May 31 2023 23:37:19 GMT+0800 (China Standard Time)

I think this should be configurable in case someone needs the old behavior.

Yep, I think your approach with the ResolutionBehavior would also fit there to control this.

Peter Csajtai · Answer 7 · Sun Jun 04 2023 08:35:53 GMT+0800 (China Standard Time)

@adambajguz, I've published v5.10.0-preview-808 with my proposal, which contains the following:

The CreateChildContainer() method got an attachToParent parameter that signals whether the child should be disposed along with the parent. It's true by default.
Each Resolve() method now accepts a ResolutionBehavior (the same one you introduced in your PR) that could indicate which container level can take part in the resolution request.
IEnumerable resolution and decorator selection now work across parent-child container relations.
I thought a lot about how the resolution from only child containers should be implemented, but I couldn't come up with a solution that would easily fit the current structure. However, as the child containers are now available on the IStashboxContainer interface through the ChildContainers property, it should be fairly easy to construct "child-only" resolution requests with ResolutionBehavior.Current on them. What do you think? Could it be a usable solution?

Could you please take a look at this version and let me know what you think? Thanks!

Adam Bajguz · Answer 8 · Sun Jun 04 2023 13:59:46 GMT+0800 (China Standard Time)

Hi @z4kn4fein,

I like the idea od Chile container identifiers.
Shouldn't this be configurable not to break the existing behavior in case someone is using it (unless you treat is as a bug)?
I think this is ok. When rethought it can alwats be added.

Peter Csajtai · Answer 9 · Sun Jun 04 2023 18:55:07 GMT+0800 (China Standard Time)

Hi @adambajguz, thanks for the feedback!

Shouldn't this be configurable not to break the existing behavior in case someone is using it (unless you treat it as a bug)?

Do you mean the IEnumerable/decorator part? If so, I believe the standard behavior should be to consider parent containers, and it was a bug not to do so previously.

Moreover, as it respects the ResolutionBehavior parameter, it's more self-explanatory now as the default is ResolutionBehavior.Defult, which includes parent containers. The old functionality is also available by resolving with ResolutionBehavior.Current.

Of course, I will state in the changelog that the default behavior of these cases changed to let those who may already have built functionality upon this bug know.

I think this is ok. When rethought it can always be added.

Sorry but I don't understand this part, could you please explain what exactly can be always added?

Carsten Schuette · Answer 10 · Sun Jun 04 2023 20:06:22 GMT+0800 (China Standard Time)

Is it possible to "extend" child containers with new service registrations? If not, where is the difference between child containers and use of scopes?

…

Message ID: ***@***.***>

Adam Bajguz · Answer 11 · Sun Jun 04 2023 20:35:22 GMT+0800 (China Standard Time)

@z4kn4fein "Do you mean the IEnumerable/decorator part?" - yes; "it was a bug not to do so previously." - ok

@schuettecarsten "Is it possible to "extend" child containers with new service registrations?" - yes, it is

@z4kn4fein "Sorry but I don't understand this part, could you please explain what exactly can be always added?" ResolutionBehavior.Children can always be added (you removed it because it is not obvious how it should work)

Peter Csajtai · Answer 12 · Mon Jun 05 2023 09:08:48 GMT+0800 (China Standard Time)

@adambajguz I've published the latest changes in v5.10.0 with the related extension packages. Please let me know if there are any issues!

@schuettecarsten Yep, as @adambajguz mentioned, it's possible. It's the main point of the child container feature.

Adam Bajguz · Answer 13 · Wed Jun 07 2023 07:15:22 GMT+0800 (China Standard Time)

Hi @z4kn4fein,
"When using the StashboxContainer as a DI container for multitenant app that utilizes generic host, it's not possible to easily activate IHostedService from child containers during host startup." - I've tested the new version of Stashbox and there's still a small issue. Imagine having ILogger service in root container and some IHostedService (s) in child container that have a dependecy to ILogger. When using child.ResolveAll<IHostedService>(ResolutionBehavior.Current) the resolution will fail. I think ResolutionBehavior should be extended with AllowDependenciesToResolveFromParent or AllowDependenciesToFallbackToParent flag.

Please let me know if you have a better solution.

Adam Bajguz · Answer 14 · Wed Jun 07 2023 07:29:29 GMT+0800 (China Standard Time)

Or maybe CurrentWithDependencyFallbackToParent = Current | 1 << 2,

Peter Csajtai · Answer 15 · Wed Jun 07 2023 22:33:39 GMT+0800 (China Standard Time)

Hey @adambajguz, I've published a new version 5.10.1-preview-811 that contains a new ParentDependency behavior. Current | ParentDependency will allow jumping up to the parent only in the dependency resolution phase. Let me know what you think!

Adam Bajguz · Answer 16 · Thu Jun 08 2023 16:50:09 GMT+0800 (China Standard Time)

Hey @z4kn4fein, thanks! The new ParentDependency flags works fine; so far I don't have any more issues.

Peter Csajtai · Answer 17 · Fri Jun 09 2023 20:28:41 GMT+0800 (China Standard Time)

@adambajguz 👍 I've released v5.10.1 with the new extension packages (v5.2.1).