Skip to content
This repository has been archived by the owner on Jan 31, 2020. It is now read-only.

Fix zendframework/zend-navigation#23 #55

Merged

Conversation

weierophinney
Copy link
Member

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 its SharedEventManager 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 to setEventManager() 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 call setDefaultListeners().
  • Internally, if an EM instance is needed, it now lazy-creates one, with a shared manager, and calls setEventManager() with the new EM instance.
  • The EM initializer in the helper plugin manager was updated to first check that we have an EventManager instance before attempting to inject one.

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 its `SharedEventManager` 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 to `setEventManager()` 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 call `setDefaultListeners()`.
- Internally, if an EM instance is needed, it now lazy-creates one, *with a
  shared manager*, and calls `setEventManager()` with the new EM instance.
- The EM initializer in the helper plugin amanger was updated to first check
  that we have an `EventManager` instance before attempting to inject one.
@weierophinney weierophinney added this to the 2.6.5 milestone Mar 21, 2016
@weierophinney weierophinney self-assigned this Mar 21, 2016
weierophinney added a commit that referenced this pull request Mar 21, 2016
@weierophinney weierophinney merged commit 67ee19c into zendframework:master Mar 21, 2016
weierophinney added a commit that referenced this pull request Mar 21, 2016
@weierophinney weierophinney deleted the hotfix/zend-navigation-23 branch March 21, 2016 18:04
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant