Zend\ServiceManager\Factory\FactoryInterface does not use Psr\Container\ContainerInterface yet

[RalfEggert]

I want to make my factories to use Psr\Container\ContainerInterface in an Zend\Expressive project. But the Zend\ServiceManager\Factory\FactoryInterface does not use Psr\Container\ContainerInterface yet.

What are the plans about this?

[kynx]

psr-11.md says this is coming in v4. Makes sense - it's a BC break - but an over-eager search-and-replace at work broke lots of stuff for me ;)

[RalfEggert]

Ok, then I guess this should include a warning:

http://zendframework.github.io/zend-expressive/reference/migration/to-v2/#psr-11-support

[RalfEggert]

Added an issue for Zend\Expressive : zendframework/zend-expressive#466

[asgrim]

Note; probably an assumption (at least on my side) but I'd expect DelegatorFactoryInterface and AbstractFactoryInterface should be updated to use Psr\Container\* at the same time as this.

[weierophinney]

Just a couple notes:

• We pin to a version of container-interop that extends the official PSR-11 interfaces.
• zend-servicemanager v3 pins to container-interop, as it pre-dates the completion of PSR-11.
• zend-servicemanager allows arbitrary callables for factories and delegators, so long as they have the minimum required arguments (a factory requires a container; delegators require a container, the service name, and a callback). The arguments do not need to follow the same typehints, however, which means they can typehint against the PSR-11 interface. (This is true for initializers as well, but you should NEVER use those.)
• Abstract factories are the only ones in wide use in Expressive that do not fit this paradigm, as we require an interface implementation; this is due to the additional method for testing if the factory can create an instance of the requested service.

Thus, the migration path is to:

• remove implementation of zend-servicemanager interfaces in your factories and delegators.
• change ContainerInterface imports to use PSR-11 in those classes.

When it comes to abstract factories, I'd argue you should likely try not to use them. They are one of the configuration types that are non-portable between different containers. Consider using the expressive factory:create tool for each class that you were previously using an abstract factory for, or, alternately, mapping each class that can be served by the abstract factory directly to it as a factory (as the implementations we directly support all accept the service name argument to the factory).

zend-servicemanager v4 will implement PSR-11 directly, and the various interfaces consuming a container will typehint against it as well. Most likely, we will allow v4 within Expressive as well as v3 once it is released, as the consumer aspects will be the same. (That said, we may do something different with aliases and invokables for v4; if we do, we'll have a v3 minor release that provides forwards compatibility, just as we did when prepping v3.)

[holtkamp]

Encountered this as well when trying to use PHP-DI as a DIC. PHP-DI already uses PSR-11, while https://github.com/zendframework/zend-servicemanager/blob/release-2.7.11/src/AbstractPluginManager.php#L12 does not, causing an error.

zend-servicemanager v4 will implement PSR-11 directly, and the various interfaces consuming a container will typehint against it as well.

This should do the trick, any plans for v4 already? It seems the development branch is not yet migrated to using PSR-11...

https://github.com/zendframework/zend-servicemanager/blob/dev-4.0/src/AbstractPluginManager.php#L10

See https://github.com/elie29/zend-di-config/issues/25 for a complete description

[thomasvargiu]

@holtkamp if you need compatibility with libraries that still use Interop Container you can decorate your PSR container:

<?php

declare(strict_types=1);

namespace App;

use Interop\Container\ContainerInterface;
use Psr\Container\ContainerInterface as PsrContainer;

class InteropContainerDecorator implements ContainerInterface
{
    /** @var PsrContainer */
    private $container;

    public function __construct(PsrContainer $container)
    {
        $this->container = $container;
    }

    public function get($id)
    {
        return $this->container->get($id);
    }

    public function has($id)
    {
        return $this->container->has($id);
    }
}

And register it as with a factory:

return [
    'dependencies' => [
        'aliases' => [
            \Interop\Container\ContainerInterface::class => \App\InteropContainerDecorator::class,
        ],
    ],
];

[holtkamp]

Thanks for the suggestions, tried a bit and this seems not to work.

Apparently Zend\Expressive\ZendView\HelperPluginManagerFactory::__construct() already adopted PSR-11 and therefore injects a Psr\Container\ContainerInterface instance, while ZendServiceManager does not.

Array
(
    [type] => 1
    [message] => Uncaught Zend\ServiceManager\Exception\InvalidArgumentException: Zend\ServiceManager\AbstractPluginManager expects a ConfigInterface or ContainerInterface instance as the first argument; received DI\Container in /user/project/vendor/zendframework/zend-servicemanager/src/AbstractPluginManager.php:59
Stack trace:
#0 /user/project/vendor/zendframework/zend-view/src/HelperPluginManager.php(253): Zend\ServiceManager\AbstractPluginManager->__construct(Object(DI\Container), Array)
#1 /user/project/vendor/zendframework/zend-expressive-zendviewrenderer/src/HelperPluginManagerFactory.php(20): Zend\View\HelperPluginManager->__construct(Object(DI\Container))
#2 [internal function]: Zend\Expressive\ZendView\HelperPluginManagerFactory->__invoke(Object(DI\Container))
#3 /user/project/vendor/p
    [file] => /user/project/vendor/zendframework/zend-servicemanager/src/AbstractPluginManager.php
    [line] => 59
)

For now using an fork of DI\Container which ALSO implements \Interop\Container\ContainerInterface does the "trick" / hack.

class Container implements \Psr\Container\ContainerInterface, \Interop\Container\ContainerInterface, FactoryInterface, InvokerInterface {
 /* rest of code */
}

A minor new release of ZendServiceManager which also accepts a PSR-11 container would be nice.

[thomasvargiu]

Oh, you're right. I think the bug is here Because HelperPluginManagerFactory is accepting a PSR container and injecting it to the HelperPluginManager which can accept only the Interop container.

So, you can use zend-view HelperPluginManager only with zend-servicemanager.

The only thing you can do at this moment is to try to use the decorated container and create your factory to instantiate the HelperPluginManager.

[elie29]

You can add in the container an alias from interop container to Psr container without the need of decorator.

[thomasvargiu]

@elie29 with PHP-DI 6.0 the container only implements the Psr container, while zend-view and other services (zend-hydrator for me) requires the interop container. Just an alias is not enough.

The decorator allowed me to use an interop container for factories that requires an interop container, but in this case I think is more a bug of zend-expressive-zendviewrenderer which its factory use a psr container but inject it to a service that requires a interop container.

[holtkamp]

@thomasvargiu thanks for the effort and ideas!

@elie29 yeah, tried that in dependencies.global.php of the skeleton Zend Expressive application:

'aliases' => [
            // Fully\Qualified\ClassOrInterfaceName::class => Fully\Qualified\ClassName::class,
            //\Interop\Container\ContainerInterface::class => \Psr\Container\ContainerInterface::class,
            \Psr\Container\ContainerInterface::class => \Interop\Container\ContainerInterface::class,
        ],

Hower it seems that Zend\Expressive\ZendView\HelperPluginManagerFactory is instantiated at the moment that the DI Container is being assembled / built by the DI ContainerBuilder => at that time the alias is not available yet...

What did function is to use the PHP-DI ContainerBuilder->wrapContainer() functionality and use the InteropContainerDecorator:

namespace Zend\DI\Config;

use App\InteropContainerDecorator;
use DI\ContainerBuilder;
use Psr\Container\ContainerInterface;
use Zend\DI\Config\ConfigInterface;

class ContainerFactory
{

    public function __invoke(ConfigInterface $config): ContainerInterface
    {
        $builder = new ContainerBuilder();
        $config->configureContainer($builder);

        $wrapperContainer = new InteropContainerDecorator();
        $builder->wrapContainer($wrapperContainer);

        $psrContainer = $builder->build();

        $wrapperContainer->setPsrContainer($psrContainer);

        return $wrapperContainer;
    }
}

But that is quite specific to https://github.com/elie29/zend-di-config, I think for now I should leave this and wait for a update to ZendServiceManager to actually use PSR-11.

[elie29]

You can kick off the container in the front controller so it is ready before other dependencies. However, phpdi is Psr compliant but not interop. So we need to wait for zend service v4

[holtkamp]

@elie29 indeed. Another option would be to add support for "PHP-DI wrapContainer functionality" in https://github.com/elie29/zend-di-config

However to me this seems like a waste of time 😄 . I am still in the orientation phase of adopting Zend Expressive with PHP-DI, so this is not a big issue for me. Will be patient 👍

[elie29]

@holtkamp I have been using zend expressive with twig and Json repsonse for almost 2 years. And I have no issues with php di v6

[thomasvargiu]

@holtkamp PHP-DI 6.0 was released on February XD

The problem is when some factory requires an interop container (that extends psr container from v1.2), but if you use a non interop compatible container, you can't inject it to that factory.

So:

• you can use an interop container with a factory that requires a psr container (from v1.2)
• you can't use a psr container with a factory that requires an interop container

If someone want to use old libraries that requires an interop container they should decorate its container to make it compatible.

But probably we are going out of topic here.

[holtkamp]

https://github.com/zendframework/zend-servicemanager/issues/184#issuecomment-434057504 Ok, I believe that, this only occurs wih ZendView.

https://github.com/zendframework/zend-servicemanager/issues/184#issuecomment-434060225 I understand the cause of the issue and I also understand the possible solutions. Since decorating the container did not succeed easily, for now my preferred solution is the simplest: have the PHI-DI Container implement both ContainerInterfaces.

But probably we are going out of topic here.

I agree, let's leave this rest for now 😄. I think I will submit an issue + PR to also "allow" a Psr\Container\ContainerInterface here https://github.com/zendframework/zend-servicemanager/blob/release-2.7.11/src/AbstractPluginManager.php#L78-L81 to enable "forward" compatibility with pure PSR-11 containers.

[elie29]

The last release of https://github.com/elie29/zend-di-config supports Interop Container in order to be used with zend view.

[panvid]

So, 3 days ago the container-interop package was marked as abandonded (see https://github.com/container-interop/container-interop/issues/94 ). Will zend-servicemanager do this BC with allowing PSR\Cotntainer\ContainerInterface in FactoryInterface?

Please no hack or new library etc. Walkarounds are ot useful for a problem, which exists since more than 2 years.

[holtkamp]

Please no hack or new library etc. Walkarounds are ot useful for a problem, which exists since more than 2 years.

What would you suggest as a (backward compatible) solution?

[weierophinney]

@dpauli We will be doing a new major release that targets the final specification; it has to be a major release, though, because it changes signatures for any code that extends our classes or implements our interfaces. (I mean, the actual signature remains the same, it's the inheritance tree that changes, but PHP doesn't make a distinction there.)

This will not happen until we transition to Laminas (which is soon). We've not done it sooner as it affects any components that provide plugin managers as well, which means those will also require new major versions. As such, it's a non-trivial change for both our libraries and our end-users.

[weierophinney]

This repository has been closed and moved to laminas/laminas-servicemanager; a new issue has been opened at https://github.com/laminas/laminas-servicemanager/issues/18.