Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[BC BREAK?] upgrade 2.8.20 -> 2.8.21 new exception #23053

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
craigh opened this issue Jun 3, 2017 · 11 comments
Closed

[BC BREAK?] upgrade 2.8.20 -> 2.8.21 new exception #23053

craigh opened this issue Jun 3, 2017 · 11 comments

Comments

@craigh
Copy link

craigh commented Jun 3, 2017

Q A
Bug report? yes
Feature request? no
BC Break report? yes?
RFC? no
Symfony version 2.8.21

I am attempting to upgrade from 2.8.20 -> 2.8.21 on composer update, I get this exception:

post-install-cmd: Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::clearCache
PHP Fatal error: Call to a member function getContainer() on null in /Applications/MAMP/htdocs/core.git/src/lib/Zikula/Bundle/CoreBundle/Console/Application.php on line 44
Script Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::clearCache handling the post-install-cmd event terminated with an exception

[RuntimeException]
An error occurred when executing the "'cache:clear --no-warmup'" command:
PHP Fatal error: Call to a member function getContainer() on null in /Applications/MAMP/htdocs/core.git/src/lib/Zikula/Bundle/CoreBundle/Console
/Application.php on line 44

Exception trace:
() at /Applications/MAMP/htdocs/core.git/src/vendor/sensio/distribution-bundle/Composer/ScriptHandler.php:293
Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::executeCommand() at /Applications/MAMP/htdocs/core.git/src/vendor/sensio/distribution-bundle/Composer/ScriptHandler.php:143
Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::clearCache() at phar:///usr/local/bin/composer/src/Composer/EventDispatcher/EventDispatcher.php:280
Composer\EventDispatcher\EventDispatcher->executeEventPhpScript() at phar:///usr/local/bin/composer/src/Composer/EventDispatcher/EventDispatcher.php:205
Composer\EventDispatcher\EventDispatcher->doDispatch() at phar:///usr/local/bin/composer/src/Composer/EventDispatcher/EventDispatcher.php:96
Composer\EventDispatcher\EventDispatcher->dispatchScript() at phar:///usr/local/bin/composer/src/Composer/Installer.php:307
Composer\Installer->run() at phar:///usr/local/bin/composer/src/Composer/Command/InstallCommand.php:119
Composer\Command\InstallCommand->execute() at phar:///usr/local/bin/composer/vendor/symfony/console/Command/Command.php:267
Symfony\Component\Console\Command\Command->run() at phar:///usr/local/bin/composer/vendor/symfony/console/Application.php:846
Symfony\Component\Console\Application->doRunCommand() at phar:///usr/local/bin/composer/vendor/symfony/console/Application.php:191
Symfony\Component\Console\Application->doRun() at phar:///usr/local/bin/composer/src/Composer/Console/Application.php:227
Composer\Console\Application->doRun() at phar:///usr/local/bin/composer/vendor/symfony/console/Application.php:122
Symfony\Component\Console\Application->run() at phar:///usr/local/bin/composer/src/Composer/Console/Application.php:100
Composer\Console\Application->run() at phar:///usr/local/bin/composer/bin/composer:54
require() at /usr/local/bin/composer:24

if I downgrade composer requirement for symfony/symfony to 2.8.20 then all returns to normal.

I have installed:

        "name": "sensio/distribution-bundle",
        "version": "v5.0.20",
@craigh
Copy link
Author

craigh commented Jun 3, 2017

the line in question is here

@craigh
Copy link
Author

craigh commented Jun 3, 2017

core composer file is here

@xabbuh
Copy link
Member

xabbuh commented Jun 3, 2017

Do you see the same when running composer update with the --no-scripts option and trying to clear the cache manually afterwards?

@craigh
Copy link
Author

craigh commented Jun 3, 2017

@xabbuh it fails on manual clearing also:

craig% php -dmemory_limit=2G /usr/local/bin/composer update --no-scripts
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 0 installs, 4 updates, 1 removal

  • Updating behat/transliterator (v1.1.0 => v1.2.0): Loading from cache
  • Updating gedmo/doctrine-extensions (v2.4.28 => v2.4.29): Loading from cache
  • Updating symfony/symfony (v2.8.20 => v2.8.21): Loading from cache
  • Updating symfony/workflow (v3.2.8 => v3.3.0): Loading from cache

Writing lock file
Generating autoload files
craig% cd src/
craig% php app/console cache:clear
PHP Fatal error: Call to a member function getContainer() on null in /Applications/MAMP/htdocs/core.git/src/lib/Zikula/Bundle/CoreBundle/Console/Application.php on line 44

@cordoval
Copy link
Contributor

cordoval commented Jun 3, 2017

@craigh give me this please

php app/console -vvv cache:clear

@craigh
Copy link
Author

craigh commented Jun 3, 2017

craig% php app/console -vvv cache:clear
PHP Fatal error: Call to a member function getContainer() on null in /Applications/MAMP/htdocs/core.git/src/lib/Zikula/Bundle/CoreBundle/Console/Application.php on line 44

@nicolas-grekas
Copy link
Member

Reproducer is easy:

git clone [email protected]:zikula/core.git
cd core
composer ins
composer up

boom
if then I force symfony/symfony 2.8.20, it's OK.

@craigh
Copy link
Author

craigh commented Jun 3, 2017

also - I pushed a branch and you can see errors on travis

@craigh
Copy link
Author

craigh commented Jun 3, 2017

@nicolas-grekas - thank you for confirming.

@xabbuh
Copy link
Member

xabbuh commented Jun 3, 2017

I had a look into it. The reason this did not happen before was the bugfix that was made in #22900. What now happens is that the parent Application class indirectly calls registerCommands() in its constructor (through add()) leading to Zikula's registerCommands() implementation being called before its $kernel property is initialized. I suggest to fix this in Zikula (see zikula/core#3595).

Though the question is if we should really do all the initialization in the Application class just because an instance of it is created. Should we maybe defer this until run() is executed?

@nicolas-grekas
Copy link
Member

Closing here as this has been resolved in Zikula.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants