Support detection of circular dependencies in dynamic factory-based registrations #7
Comments
|
The unit test |
craigfowler
changed the title
|
I need to research and determine whether or not I can do this and maintain the backwards compatibility for resolving factory-based dependencies. In this case, backwards compatibility means "using the IObjectContainer" interface. I am not going to worry about the difference in functionality between MicroDi and the original BoDi in this instance, because BoDi would have crashed on a stack overflow exception in that case. So it was always broken/bugged. In this case, all I'm going to do is fix that bug so that it correctly raises a circular dependency exception. |
|
If this turns out to be a breaking change then I will defer it to after v1.0. At present I'm going to proceed as if it's not. |
|
I think the technique here would be a custom resolver proxy, inside the BoDi compatibility layer project. This would detect resolution requests for Then - when that container is used to resolve services - is resolution requests should begin their request path at the point of the injected path. |
|
It looks like I may have to proxy the object container itself to do this, as subclassing it is not an option (methods not virtual). |
|
Adding an extra proxy to the resolver will be blocked by #26. |
…solve This will use the same resolution path as was used to resolve it - and so the resolution path chain is not broken by re-entering the container.
…resolver factory This means that BoDi will always add that extra proxy into the queue of proxies, so requests for an IObjectContainer will actually get the newly-created dynamic resolution object container proxy and not the real implementation.
There is a very old branch in the repo by the name of
factory_reg. This seems to have dealt with circular-dependency detection in some manner (in dynamic factory-based registrations). It may or may not contain useful code to move this forward.The problem here is that the factory delegate used to resolve the inner service is receiving an IObjectContainer instance. This means that we start the whole resolution process from scratch instead of continuing the same resolution operation. Thus - the resolution path is lost in the process and a new one is started afresh. The issue there of course is that because we use that path to detect circular dependencies, we will never succeed.
What would need to happen here is to substitute the actual implementation passed to the factory resolution process; something a little smarter. This way, when using a factory registration (which allows dynamic resolution of contained services) we can continue from the existing resolution path, essentially injecting it into the new resolve operation.
This might be a breaking change for backwards compatibility with BoDi, or it might not.
The text was updated successfully, but these errors were encountered: