Bug #67209
closed
Calling InstallTools ClearCacheService->clearAll() from CLI leads to php fatal
Added by Daniel Goerz almost 9 years ago.
Updated almost 9 years ago.
Description
I just stumbled over an issue with calling clearAll()
in \TYPO3\CMS\Install\Service\ClearCacheService
from CLI.
I created a litte Extension that you can use to reproduce this on github: https://github.com/ervaude/bug_reproduce
Basically it adds an CommandController that calls the mentioned function. If you install the extension and run the cli command, you will be able to reproduce this error (at least I was):
./typo3/cli_dispatch.phpsh extbase cacheapi:clearallcaches
PHP Fatal error: Nesting level too deep - recursive dependency? in .../typo3/sysext/extbase/Classes/SignalSlot/Dispatcher.php on line 94
I debugged var_dump($slotMethodName)
all the Slots that were called before the fatal to get closer to the problem, but I failed to find a solution. Anyway here is the debug output:
./typo3/cli_dispatch.phpsh extbase cacheapi:clearallcaches
string(27) "addUserPermissionsToStorage"
string(21) "scanAvailablePackages"
string(20) "removeFromRepository"
string(32) "cleanupProcessedFilesPostFileAdd"
string(36) "cleanupProcessedFilesPostFileReplace"
string(22) "buildStaticMappingFile"
string(22) "buildStaticMappingFile"
string(22) "buildSpriteHtmlIconTag"
string(22) "buildSpriteIconClasses"
string(59) "addCachingFrameworkRequiredDatabaseSchemaToTablesDefinition"
string(43) "addCategoryDatabaseSchemaToTablesDefinition"
string(21) "scanAvailablePackages"
string(59) "addCachingFrameworkRequiredDatabaseSchemaToTablesDefinition"
string(52) "addExtensionCategoryDatabaseSchemaToTablesDefinition"
string(36) "addUserPermissionsToCategoryTreeData"
string(14) "processActions"
string(13) "appendMessage"
string(27) "addUserPermissionsToStorage"
string(21) "scanAvailablePackages"
string(20) "removeFromRepository"
string(32) "cleanupProcessedFilesPostFileAdd"
string(36) "cleanupProcessedFilesPostFileReplace"
string(22) "buildStaticMappingFile"
PHP Fatal error: Nesting level too deep - recursive dependency? in ...typo3/sysext/extbase/Classes/SignalSlot/Dispatcher.php on line 95
This fatal does not occure on 6.2.12!
- Category set to Backend API
- Target version set to 7.3 (Packages)
- Sprint Focus set to Stabilization Sprint
Update: This fatal only occures if composer class loading is not used.
If you are not using composer class loading, you can nail it down to the slots being registered (and called) in sysext:core ext_localconf.php
lines 43-60
if (!\TYPO3\CMS\Core\Core\Bootstrap::usesComposerClassLoading()) {
$bootstrap = \TYPO3\CMS\Core\Core\Bootstrap::getInstance();
$classAliasMap = $bootstrap->getEarlyInstance(\TYPO3\CMS\Core\Core\ClassAliasMap::class);
$signalSlotDispatcher->connect(
\TYPO3\CMS\Extensionmanager\Service\ExtensionManagementService::class,
'hasInstalledExtensions',
$classAliasMap,
'buildStaticMappingFile'
);
$signalSlotDispatcher->connect(
\TYPO3\CMS\Extensionmanager\Utility\InstallUtility::class,
'afterExtensionUninstall',
$classAliasMap,
'buildStaticMappingFile'
);
unset($bootstrap, $classAliasMap);
}
If you skip this code, the fatal disappears.
- Status changed from New to Needs Feedback
can't reproduce the fatal, can you please tell us the concrete PHP version?
I have testet it with your extension and PHP 5.5.23 and 5.6.7 both works without fatal.
So far, I encountered that error on the following setups:
- OSX 10.10.3 - PHP 5.5.21
- CentOS release 6.6 - PHP 5.5.22
Composer class loading was not used in either setup.
Also appeared on 7.2 and master on
- Ubuntu 14.04.2 - PHP 5.5.9-1ubuntu4.9
How do you "disable" Composer class loading?
master always uses the composer class loader for Core classes.
The core checks for the composer autoload.php only at one place (code is from \TYPO3\CMS\Core\Core\Bootstrap line 216ff):
static protected function initializeComposerClassLoader() {
$possiblePaths = array(
'distribution' => __DIR__ . '/../../../../../../Packages/Libraries/autoload.php',
'fallback' => __DIR__ . '/../../../../contrib/vendor/autoload.php',
);
[...]
(It is the distribution
array key)
So only if in your documentRoot the folders ./Packages/Libraries/ exist and are used as composers vendor folder (you have to configure this in your composer.json) only then is composer class loading used.
[...]
if ($autoLoadType === 'distribution') {
self::$usesComposerClassLoading = TRUE;
}
[...]
So to "disable" composer class loading you just have to make composer use its default vendor folder "vendor".
I'm still not fully clear about how you use the Core.
Did you install it the "classic" way by downloading the source, or are you using it as "library" in a distribution defining a project-level composer.json?
My workflow is simple:
To initialize a TYPO3 Website I create a composer.json like this:
{
"name": "danielgoerz/newProject",
"description": "New awesome TYPO3 project",
"homepage": "link to git repo",
"config": {
"vendor-dir": "Packages/Libraries/"
},
"repositories": [
{"type": "composer", "url": "http://composer.typo3.org"}
],
"require": {
"typo3/cms": "7.2.*",
// Extensions go here
}
}
composer update
now pretty much does the trick.
You see the vendor-dir thingy in the composer.json
I'm finally totally confused.
You're using the Core via composer, but above you said
Composer class loading was not used in either setup
That does not make sense to me.
Additionally, the Core now dropped the internal class loader completely, so maybe you can give this another shot with current master.
Well, it does make sense, because the core looks only in Packages/Libraries/
if a autoload.php
exists.
If I dont specify this vendor-dir in my composer.json, composer will put its autoload.php
inside the vendor
directory by default.
And in that case I use the core with composer but internally (in \TYPO3\CMS\Core\Core\Bootstrap) self::$usesComposerClassLoading
will always be FALSE
.
And that is what I ment with " Composer class loading was not used ".
I didnt ment to confuse you, but this is kind of a confusing topic to me, too. I dont know how to explain it better =)
Got that now. The point is: You posted a json with vendor-dir, but you actually use it without vendor-dir.
That will not work.
- Sprint Focus deleted (
Stabilization Sprint)
- Target version changed from 7.3 (Packages) to 7.4 (Backend)
On current master I am not able to reproduce the fatal.
So I guess we can close this issue?
- Status changed from Needs Feedback to Closed
- Target version deleted (
7.4 (Backend))
Also available in: Atom
PDF