This repository has been archived by the owner on Jan 31, 2020. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Running tests of zend-navigation against all v2 components (no v3 components) revealed a circular dependency condition in the navigation helpers related to
getEventManager()
.In v2,
getEventManager()
has lazy-loaded an EM instance, and an initializer was checking the returned instance to see if itsSharedEventManager
instance was present and/or the same as the one in the container; if not, it was re-injecting the EM instance from the container. Unfortunately, this fails now, as the call tosetEventManager()
now attaches the default listeners, and requires that a shared manager is present.This patch changes the behavior to the following:
getEventManager()
now never lazy-loads an instance. This ensures that the initializer doesn't lead to lazy-population of the shared manager.setEventManager()
was updated to check that we have a shared manager before attempting to callsetDefaultListeners()
.setEventManager()
with the new EM instance.EventManager
instance before attempting to inject one.