The ServiceListener::onLoadModulesPost() listener raises an exception if a given plugin manager instance is unavailable, and does not exist in the application service manager. This impacts migrating the various plugin managers to their respective components:
If they are registered as part of the module configuration, but that component is not present, then an exception is raised.
We cannot add delegator factories on the ServiceListener from component module classes, as the ServiceListener is retrieved before loading modules.
One solution is to assume that if the plugin manager is not present, nothing needs to be done. This allows components to map the plugin loader services they expose via their Module classes, ensuring that once the listener triggers, it can access the service and configure it.
Incidentally, there is also a solution to components notifying the ServiceListener of plugin manager specifications already, via the init() method. As an example:
namespace Some\Component;
class Module
{
public function init($event)
{
$container = $event->getParam('ServiceManager');
$serviceListener = $container->get('ServiceListener');
$serviceListener->addServiceManager(/* ... */);
}
}
As components are expected to be listed early in the module list, this approach should be robust enough to ensure userland and third party modules (not components) registered later can configure the plugin manager.
The patch submitted ensures that in the off chance that a plugin manager is registered but has no service associated with it, exceptions need not be thrown.
The
ServiceListener::onLoadModulesPost()
listener raises an exception if a given plugin manager instance is unavailable, and does not exist in the application service manager. This impacts migrating the various plugin managers to their respective components:ServiceListener
from component module classes, as theServiceListener
is retrieved before loading modules.One solution is to assume that if the plugin manager is not present, nothing needs to be done. This allows components to map the plugin loader services they expose via their
Module
classes, ensuring that once the listener triggers, it can access the service and configure it.Incidentally, there is also a solution to components notifying the
ServiceListener
of plugin manager specifications already, via theinit()
method. As an example:As components are expected to be listed early in the module list, this approach should be robust enough to ensure userland and third party modules (not components) registered later can configure the plugin manager.
The patch submitted ensures that in the off chance that a plugin manager is registered but has no service associated with it, exceptions need not be thrown.