-
Notifications
You must be signed in to change notification settings - Fork 89
Better ServiceLocatorAware deprecation #88
Better ServiceLocatorAware deprecation #88
Conversation
We were: - injecting any service that *was not* marked as `ServiceLocatorAware` but implemented `setServiceLocator()`, and - injecting any service that *was* marked `ServiceLocatorAware`, and - emitting a deprecation notice in both cases. The rationale was to allow backwards compatibility with existing implementations, while still messaging to users that they need to update their code not to rely on that. This created a few problems, though: - *Every* controller inheriting from `AbstractController` now emits deprecation notices on instantiation. - Developers who had implemented a `setServiceLocator()` method without implementing `ServiceLocatorAwareInterface` were now getting auto-injected with the service locator instance when they did not expect to. This patch attempts to address those issues as follows: - `ServiceManagerConfig` updates its service locator initializer to: - Inject non-plugin manager `ServiceLocatorAware` instances; in this situation, a deprecation notice *is* emitted. - For `ServiceLocatorAware` plugin managers, it checks to see if a service locator is already composed. If not, it will inject it, but then emit a deprecation notice indicating that the service locator should be injected as a constructor parameter. - `ControllerManager` updates its service locator initializer to: - For non-`ServiceLocatorAware` `AbstractController` implementations, it injects the service locator with no notices. - For all explicitly `ServiceLocatorAware` controllers, it injects the service locator *and* emits a deprecation notice. - It no longer injects non-`ServiceLocatorAware` controllers that implement `setServiceLocator()` unless they extend `AbstractController`. This is fully backwards compatible. - `AbstractController::getServiceLocator()` now emits a deprecation notice prior to returning the service locator instance. This is more appropriate, as we want to encourage users who rely on the service locator composition to upgrade. Interestingly, this allows us to revert a number of changes that were made to the tests to mask deprecation notices, which helps solidify the argument that the original changes were indeed a backwards compatibility break, and that the new changes will address that situation.
Better! 👍 |
Much better! 👍 |
I see one case which allow users to use service locator in controllers without warning - by serviceLocator property. Are we should care about this? @weierophinney |
@snapshotpl Too difficult to manage (we'd have to use property overloading, and that gets messy fast). Those users will feel the pain when they upgrade to zend-mvc v3 later, and it will be covered in the migration guide at that time. |
@weierophinney Thanks, it works on our project now and we do not encounter the deprecated warning 👍 |
I encountered a problem regarding this deprecation: Sample Code:
Output:
The job silently dies when I call a function of doctrine. |
Problem fixed. Doctrine-only problem. |
Hi! Could you please explain me how I can have this patch in my local project please ? |
@chrisVdd
|
This is a patch for fixing #87.
We were:
ServiceLocatorAware
but implementedsetServiceLocator()
, andServiceLocatorAware
, andThe rationale was to allow backwards compatibility with existing implementations, while still messaging to users that they need to update their code not to rely on that.
This created a few problems, though:
AbstractController
now emits deprecation notices on instantiation.setServiceLocator()
method without implementingServiceLocatorAwareInterface
were now getting auto-injected with the service locator instance when they did not expect to.This patch attempts to address those issues as follows:
ServiceManagerConfig
updates its service locator initializer to:ServiceLocatorAware
instances; in this situation, a deprecation notice is emitted.ServiceLocatorAware
plugin managers, it checks to see if a service locator is already composed. If not, it will inject it, but then emit a deprecation notice indicating that the service locator should be injected as a constructor parameter.ControllerManager
updates its service locator initializer to:ServiceLocatorAware
AbstractController
implementations, it injects the service locator with no notices.ServiceLocatorAware
controllers, it injects the service locator and emits a deprecation notice.ServiceLocatorAware
controllers that implementsetServiceLocator()
unless they extendAbstractController
. This is fully backwards compatible.AbstractController::getServiceLocator()
now emits a deprecation notice prior to returning the service locator instance. This is more appropriate, as we want to encourage users who rely on the service locator composition to upgrade.Interestingly, this allows us to revert a number of changes that were made to the tests to mask deprecation notices, which helps solidify the argument that the original changes were indeed a backwards compatibility break, and that the new changes will address that situation.