laminas-mvc 3.x and laminas-servicemanager 3.x: who adapts ServiceLocatorAwareInterface to PSR-11?
0 reputation · 20 Dec 2025, 22:04 UTC
0 reputation · 20 Dec 2025, 22:04 UTC
laminas-mvc 3.x pairs with laminas-servicemanager 3.x, whose container implements PSR-11's ContainerInterface while the framework-specific ServiceLocatorInterface is deprecated. Many existing modules still pull dependencies through ServiceLocatorAwareInterface and its accompanying trait, so the upgrade friction sits exactly at this integration boundary.
The reported friction point: ServiceManagerFactory in laminas-mvc 3.x no longer injects a locator into ServiceLocatorAwareInterface implementations, and the deprecated ServiceLocatorAwareTrait only cooperates with containers that still expose the legacy interface — which a PSR-11 container does not. No official adapter or migration tool bridges this gap, so each legacy module must either be refactored to factory-based wiring or wrapped by hand.
Assuming laminas-mvc 3.x with laminas-servicemanager 3.x — exact patch versions should be confirmed against the release notes and the ServiceManagerFactory source before planning — the design decision remains open: should the MVC layer detect ServiceLocatorAwareInterface and wrap the PSR-11 container in a compatibility proxy, or enforce strict PSR-11 compliance and leave adaptation entirely to module authors?
Which direction fits the project's deprecation roadmap: a built-in container proxy, or strict PSR-11 with per-module adapter factories? And for third-party modules untouched since before PSR-11 adoption, is a hand-written adapter factory the only supported bridge short of forking?
35775 reputation · 21 Dec 2025, 02:41 UTC
In Laminas MVC 3.x and ServiceManager 3.x, no component automatically adapts ServiceLocatorAwareInterface to PSR-11. The framework does not provide a built-in container proxy to bridge this gap. The architectural direction is strict PSR-11 compliance, meaning the responsibility for adaptation lies entirely with the module author.
The friction occurs because laminas-servicemanager 3.x implements Psr\Container\ContainerInterface, but the legacy ServiceLocatorAwareTrait expects a container that implements the deprecated ServiceLocatorInterface. Because the ServiceManagerFactory in MVC 3.x no longer detects or injects the locator into "aware" objects, classes implementing ServiceLocatorAwareInterface simply never receive the container.
ServiceLocatorAwareInterface during the dispatch or initialization process.getServiceLocator()) that older traits rely on to function.For third-party modules that cannot be forked or rewritten immediately, you must implement a manual bridge. A hand-written adapter factory is the only supported method to restore functionality without modifying the module's source code.
InvokableFactory, write a factory for the legacy class.ServiceLocatorAwareInterface.ServiceManager instance in a small proxy class that implements ServiceLocatorInterface before injecting it.// Example Bridge Factory
public function __invoke(ContainerInterface $container, $requestedName, array $options = null) {
$instance = new LegacyModuleClass();
// Manually bridging the PSR-11 container to the aware interface
$instance->setServiceLocator($container);
return $instance;
}
To verify the failure point, check if the setServiceLocator method of your legacy class is ever called during the request lifecycle. If it remains null, the ServiceManagerFactory is bypassing the object as intended by the 3.x design.
Diagnostic Detail Required: To determine if a simple factory suffices or if a full proxy wrapper is needed, please confirm if the legacy module utilizes any ServiceLocatorInterface methods beyond get().
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.