Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix proposal for issue 293 (resolving singletons in the root container) implemented on v5.x (5.10.3) #167

Closed
wants to merge 2 commits into from

Conversation

jarikp
Copy link

@jarikp jarikp commented May 22, 2019

The original problem is discussed here https://github.com/unitycontainer/unity/issues/293
This is a suggested fix, wich resolves run-time issues caused by it. I hope, it covers all cases, but please let me know if I missed something or my assumptions about the Resolve() flows are incorrect.

Jarik Poplavski added 2 commits May 21, 2019 16:13
…t container and are always awailable. This fix address the situation when a singleton resolved in a child container, might become corrupt (if it held references to factories), when the child container was closed/disposed.
…t container and are always awailable, part 2. Includes fix to BuilderContext.Resolve() and some DRY-refactoring.
@jarikp
Copy link
Author

jarikp commented May 22, 2019

Hmm, looks like the "latest" from the v5.x branch is not able to complile due to some argument mismatch in the exception ctor... Not related to my changes.

@ENikS
Copy link
Contributor

ENikS commented May 22, 2019

Unfortunately I have to decline this PR. As I explained in the original topic, this behavior is by design and should not be changed.

@ENikS ENikS closed this May 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants