Implement ResolverHierarchyAccess configuration #567
Conversation
There is currently the potential for unexpected behavior when resolving entries from parent containers where a parent registration can access and store objects resolved from a child container (see unit tests). This introduces a configuration to modify this access.
8efecbe to
da9ee0f
Compare
| @@ -58,9 +71,10 @@ public final class Container { | |||
| parent: Container? = nil, | |||
| defaultObjectScope: ObjectScope = .graph, | |||
| behaviors: [Behavior] = [], | |||
| registeringClosure: (Container) -> Void = { _ in } | |||
| registeringClosure: (Container) -> Void = { _ in }, | |||
| resolverHierarchyAccess: ResolverHierarchyAccess = .receiver | |||
There was a problem hiding this comment.
I left the default here as the current behavior, but it would be nice to discuss changing the default in a future version.
| XCTAssert(child.resolve(Animal.self, name: "Spot") is Cat) | ||
| // The instance provided by the child leaks into the parent | ||
| XCTAssert(parent.resolve(Animal.self, name: "Spot") is Cat) |
There was a problem hiding this comment.
Also want to call attention to this test case as this behavior is the most unexpected/problematic of the way things currently work
|
Will look at this soon to see if I can merge this as part of a new release cut. |
There is a potential bug with resolution when using parent-child containers and shadowed registrations. This fix ensures that when performing resolution that a parent container can never have access to registrations in a child container. Previously, the container that received the `resolve()` call was captured and used for later factory invocations, and if that receiver was a child that also had a shadowed registration of the parent then the bug could emerge. This implements the same change as Swinject/Swinject#567 but does not retain an option to use the old behavior. Instead, we are considering the old Swinject behavior to be a bug, and are directly fixing for Knit.
|
When testing this change @skorulis-ap discovered that it does not work properly with the way that synchronized containers are set up. This is due to the part where the synchronized container contains no service entries, all entries are on the unsynchronized container, which means the modified |
There is currently the potential for unexpected behavior when resolving entries from parent containers where a parent registration can access and store objects resolved from a child container (see unit tests). This introduces a configuration to modify this access.