Our project is partly made of three bundles, two of them consist of a web backend application and an associated API consumed by our Customer's Frontend Single Page Application, the last one "CoreBundle" is where common resources live.
These bundles all have a DependencyInjection's (DI) bundle sub-directory but do not have Configuration class at all since none of them has any specific configuration. We use the DI component as suggested in the documentation, there is in theory no special case in this project that may influence the configuration loading mechanism.
This has been working well Until now (Symfony 3.3.2).
In an intent of updating symfony/symfony from 3.3.2 to 3.4, composer post-install script Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::clearCache generates 2 exceptions:
In Consistency.php line 337: Class Bundle\CoreBundle\DependencyInjection\Configuration\Configuration not found
In Consistency.php line 285: Class Bundle\CoreBundle\DependencyInjection\Configuration\Configuration not found
Exception trace:
Exception trace:
Hoa\Core\Consistency\Consistency::autoload() at n/a:n/a
call_user_func() at /var/www/back-portal/vendor/symfony/symfony/src/Symfony/Component/Debug/DebugClassLoader.php:146
Symfony\Component\Debug\DebugClassLoader->loadClass() at n/a:n/a
spl_autoload_call() at n/a:n/a
class_exists() at /var/www/back-portal/vendor/symfony/symfony/src/Symfony/Component/Config/Resource/ClassExistenceResource.php:78
Symfony\Component\Config\Resource\ClassExistenceResource->isFresh() at /var/www/back-portal/vendor/symfony/symfony/src/Symfony/Component/DependencyInjection/ContainerBuilder.php:351
Symfony\Component\DependencyInjection\ContainerBuilder->getReflectionClass() at /var/www/back-portal/vendor/symfony/symfony/src/Symfony/Component/DependencyInjection/Extension/Extension.php:84
Symfony\Component\DependencyInjection\Extension\Extension->getConfiguration() at /var/www/back-portal/vendor/symfony/symfony/src/Symfony/Component/DependencyInjection/Compiler/MergeExtensionConfigurationPass.php:63
Symfony\Component\DependencyInjection\Compiler\MergeExtensionConfigurationPass->process() at /var/www/back-portal/vendor/symfony/symfony/src/Symfony/Component/HttpKernel/DependencyInjection/MergeExtensionConfigurationPass.php:39
Symfony\Component\HttpKernel\DependencyInjection\MergeExtensionConfigurationPass->process() at /var/www/back-portal/vendor/symfony/symfony/src/Symfony/Component/DependencyInjection/Compiler/Compiler.php:141
Symfony\Component\DependencyInjection\Compiler\Compiler->compile() at /var/www/back-portal/vendor/symfony/symfony/src/Symfony/Component/DependencyInjection/ContainerBuilder.php:760
Symfony\Component\DependencyInjection\ContainerBuilder->compile() at /var/www/back-portal/vendor/symfony/symfony/src/Symfony/Component/HttpKernel/Kernel.php:625
Symfony\Component\HttpKernel\Kernel->initializeContainer() at /var/www/back-portal/vendor/symfony/symfony/src/Symfony/Component/HttpKernel/Kernel.php:137
Symfony\Component\HttpKernel\Kernel->boot() at /var/www/back-portal/vendor/symfony/symfony/src/Symfony/Bundle/FrameworkBundle/Console/Application.php:63
Symfony\Bundle\FrameworkBundle\Console\Application->doRun() at /var/www/back-portal/src/Component/MultiApp/MultiAppConsoleApplication.php:35
Component\MultiApp\MultiAppConsoleApplication->doRun() at /var/www/back-portal/vendor/symfony/symfony/src/Symfony/Component/Console/Application.php:129
Symfony\Component\Console\Application->run() at /var/www/back-portal/bin/console:31
Adding a Configuration class, with its getConfigTreeBuilder() method returning a new ("empty") Treebuilder instance, makes the exception point out another bundle. I did so for our three bundles and the exception now points out one of Sensio's own bundles instead.
In Consistency.php line 337: Class Sensio\Bundle\DistributionBundle\DependencyInjection\Configuration\Configuration not found …</p>
Here are a few Composer warnings spawning before the exception gets thrown:
Dependency "symfony/polyfill-apcu" is also a root requirement, but is not explicitly whitelisted. Ignoring.
…
Package hoa/core is abandoned, you should avoid using it. Use hoa/consistency instead.
Package guzzle/guzzle is abandoned, you should avoid using it. Use guzzlehttp/guzzle instead.
Executing rm -rf var/cache/* did not help.
Running only bin/console cache:clear throws this same exception.
Now that our bundles implementation seem to not have anything to do with this issue, I have even less idea of what may be the root of the problem. That said, the line "spl_autoload_call() at n/a:n/a" looks strange …
May be some Symfony dependencies should be forced to some versions … ? (By the way changelog did not provide helpful hint of a potential cause)
Thank you for your help.