I'm using the \Zend\ServiceManager\Di\DiAbstractServiceFactory to initialize objects and resolve their dependencies. But I have an issue with recursion in the \Zend\ServiceManager\ServiceManager::has.

I've added the \Zend\ServiceManager\Di\DiAbstractServiceFactory (it's also not a trivial task because service manager calls new during abstract factory initialization) to list of abstract factories.

During object initialization by ServiceManager via DiAbstractServiceFactory the \Zend\ServiceManager\Di\DiServiceFactory::get will be called to create the object and this method calls \Zend\ServiceManager\ServiceManager::has to check if ServiceManager can create this object; in its turn ServiceManager will check if configured abstract factories have possibility to create this object.

This behavior in the couple of \Zend\ServiceManager\Di\DiServiceFactory::get implementation causes the circular recursion. The previous implementation of \Zend\ServiceManager\ServiceManager::has was smarter and didn't have this issue.

Specifying \Zend\ServiceManager\Di\DiServiceFactory::USE_SL_AFTER_DI during DiAbstractServiceFactory doesn't solve this issue because other dependencies cannot be resolved.

zend-servicemanager-di 1.1.0 zend-servicemanager 3.3.0

Originally posted by @joni-jones at https://github.com/zendframework/zend-servicemanager/issues/186

• [x] I was not able to find an open or closed issue matching what I'm seeing.
• [x] This is not a question. (Questions should be asked on chat (Signup here) or our forums.)

The Zend\ServiceManager\Di\DiAbstractServiceFactory when used as an abstract factory is causing recursion.

The issue is caused by Zend\ServiceManager\ServiceManager::has() function implementation and Zend\ServiceManager\Di\DiAbstractServiceFactoryFactory: :__invoke() function which is using DiAbstractServiceFactory::USE_SL_BEFORE_DI and Zend\ServiceManager\Di\DiServiceFactory: :get() method which is sending the object initialization request back to the Zend\ServiceManager\ServiceManager and as a result creating the recursion.

During object initialization by ServiceManager via DiAbstractServiceFactory the DiServiceFactory::get() method checks whether it should call ServiceManager (Service Locator) first by the following code (line 126) and therefore sends the object initialization request back to the ServiceManager because both conditions for the if statement are correct in this situation.

// Allow this di service to get dependencies from the service locator BEFORE trying DI.
if ($this->useContainer === self::USE_SL_BEFORE_DI && $this->container->has($name)) {    
     return $this->container->get($name);
 }

As the object initialization request is sent or pushed back to the ServiceManager and the ServiceManager will forward the request again to DiAbstractServiceFactory therefore creating the recursion (sending the request back and forth) and the end result is system memory exhausted.

Code to reproduce the issue

Please just use Zend\ServiceManager\Di\DiAbstractServiceFactory as an abstract factory and then use ServiceManager to get/initialize an object. This object should not have any other factory class defined in the config. The only factory which should initialize this object should be Zend\ServiceManager\Di\DiAbstractServiceFactory.

Expected results

No Recursion.

Actual results

Recursion

Originally posted by @mirza572 at https://github.com/zendframework/zend-servicemanager-di/issues/19

Feature Request

| Q | A |------------ | ------ | New Feature | yes

Summary

To be prepared for the december release of PHP 8.0, this repository has some additional TODOs to be tested against the new major version.

In order to make this repository compatible, one has to follow these steps:

• [ ] Modify composer.json to provide support for PHP 8.0 by adding the constraint ~8.0.0
• [ ] Modify composer.json to drop support for PHP less than 7.3
• [ ] Modify composer.json to implement phpunit 9.3 which supports PHP 7.3+
• [ ] Modify .travis.yml to ignore platform requirements when installing composer dependencies (simply add --ignore-platform-reqs to COMPOSER_ARGS env variable)
• [ ] Modify .travis.yml to add PHP 8.0 to the matrix (NOTE: Do not allow failures as PHP 8.0 has a feature freeze since 2020-08-04!)
• [ ] Modify source code in case there are incompatibilities with PHP 8.0

Feature Request

| Q | A |------------ | ------ | QA | yes

Summary

As decided during the Technical-Steering-Committee Meeting on August 3rd, 2020, Laminas wants to implement vimeo/psalm in all packages.

Implementing psalm is quite easy.

Required

• [ ] Create a .psalm.xml.dist in the project root
• [ ] Copy and paste the contents from this psalm.xml.dist
• [ ] Run $ composer require vimeo/psalm
• [ ] Run $ vendor/bin/psalm --set-baseline=psalm-baseline.xml
• [ ] Add a composer script static-analysis with the command psalm --shepherd --stats
• [ ] Add a new line to script: in .travis.yml: - if [[ $TEST_COVERAGE == 'true' ]]; then composer static-analysis ; fi
• [ ] Remove phpstan from the project (phpstan.neon.dist, .travis.yml entry, composer.json require-dev and scripts)

Optional

• [ ] Fix as many psalm errors as possible.