Is there an extension point where we can create a new/nested ioc container on each request (the default way of how structuremap should be used, see http://structuremap.github.io/the-container/nested-containers/)
If you're looking for callbacks you can fire before and after each request you can use:
When you create the nested container what do you intend to do with it? add it to
IRequest.Items then retrieve back later on in the pipeline from there?
It will depend on your advice.
So whenever we ask for an IContainer it should use the IContainer from the PreRequestFilter where the container was created as a NestedContainer.
In Core 1.1 you can use the IServiceScopeFactory
A quote from the documentation of structuremap:
Why Nested Containers over HttpContext or ThreadLocal Scoping?
Why not just use HttpContext based lifecycles like we've always done in the past? Because HttpContext is not supported by any type of OWIN web host and will not be a part of ASP.Net vNext. Using a Nested Container per HTTP request is a better, lighterweight way to scope services to an HTTP request without coupling your code to what will soon be legacy ASP.Net runtime code.
You're not going to be able to inject the nested Container to replace the AppHost Container, that's a singleton container that's pre hardwired to use the registered Container Adapter.
That's why I asked, I only see you adding it to
IRequest.Items then if you later want a dependency from the nested Container first check
IRequest.Items for the nested container, if it's there use it otherwise fallback to the AppHost container.
Ok, but then auto-resolving dependencies in services won't work.
ps. The .NET Core is also using a nested container approach
Funq also has a CreateChildContainer method, but it's not used in servicestack at the moment..
How does the current Funq container handle singleton registrations?
Not sure what you mean, it's singleton by default and injects the same instance.
In the AppHost.Release every instance is diposed (if IDisposable), but maybe i'm missing something, still new to the codebase..
It doesn't add singletons to the track disposables list.
ahh I missed this line
Adding a custom ContainerAdapter allows your services to resolve its dependencies from an alternative IOC, in this way they act like a dependency repository where the services are still registered in Funq but all their dependencies are resolved by the ContainerAdapter specified.
So you have to register the dependies in both Funq and the IContainerAdapter...
No, it's saying Services (i.e classes inheriting ServiceStack's Service) class is still registered in Funq, but all its dependencies are resolved through the Container Adapter.
It doesn't affect where you want to register dependencies which you can choose to register in either Funq or your preferred IOC.