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.

mythz
—
2017-03-15T12:08:52Z —
#4

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.

Funq also has a CreateChildContainer method, but it's not used in servicestack at the moment..

mdissel
—
2017-03-18T18:16:30Z —
#7

How does the current Funq container handle singleton registrations?

mythz
—
2017-03-18T18:31:20Z —
#8

Not sure what you mean, it's singleton by default and injects the same instance.

mdissel
—
2017-03-18T19:07:51Z —
#9

In the AppHost.Release every instance is diposed (if IDisposable), but maybe i'm missing something, still new to the codebase..

mythz
—
2017-03-18T23:07:33Z —
#10

It doesn't add singletons to the track disposables list.

mdissel
—
2017-03-19T09:50:00Z —
#11

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...

mythz
—
2017-03-19T13:47:24Z —
#12

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.

mdissel
—
2017-04-22T08:58:41Z —
#13

I've examined the code a bit more and have questionIf you register an object in the container adapter (not in funq) with a singleton scope and it's resolved by Funq, how does Funq know the scope of the resolved service (and/or nested resolved services)?

mythz
—
2017-04-22T12:17:32Z —
#14

Funq can't know the reuse scope in an external IOC.

mdissel
—
2017-04-22T14:44:01Z —
#15

But then it's better to not use an external IOC/the adapter feature. Correct?