ZF-6545: Zend_Application_Module_Bootstrap doesn't work

Issue Type: Bug Created: 2009-05-05T14:44:37.000+0000 Last Updated: 2009-05-12T06:53:47.000+0000 Status: Resolved Fix version(s): - 1.8.1 (12/May/09)

Reporter: Rudolf Beranek (maac) Assignee: Matthew Weier O'Phinney (matthew) Tags: - Zend_Application

Related issues: Attachments:


I think, that problem lies in constructor where is never calling parent class (Zend_Application_Bootstrap_Bootstrap) for initializing front controller. When I insert to constructor on first line calling parent class, modules then works fine.


Posted by Matthew Weier O'Phinney (matthew) on 2009-05-06T06:01:33.000+0000

I'm reading this request not as it doesn't work, but as a feature request to have Zend_Application_Module_Bootstrap extend Zend_Application_Bootstrap_Bootstrap instead of Zend_Application_Bootstrap_BootstrapAbstract.

Posted by Matthew Weier O'Phinney (matthew) on 2009-05-06T06:02:28.000+0000

Ooops -- it already does, and is simply missing the call to parent::__construct(), as you note in your comment. Fixing.

Posted by Matthew Weier O'Phinney (matthew) on 2009-05-06T06:40:31.000+0000

Patched in trunk and 1.8 release branch.

Posted by Jorge Padron (jpadron) on 2009-05-06T20:33:50.000+0000

After this patch, my app doesn't work. No error trapped neither blank screen, only the message from firefox "can't found the page".

I have the standard modular structure:

application Bootstrap.php ----Configs --------application.ini modules --------default --------------controllers --------------models --------------views --------module1 --------------Bootstrap.php --------------controllers --------------models --------------views --------module2 --------------Bootstrap.php --------------controllers --------------models --------------views library public

The main bootstrap.php extends Zend_Application_Bootstrap_Bootstrap (only one method to _initLogger), and the bootstrap module's extends Zend_Application_Module_Bootstrap without any method.

And application ini, contains this settings:

phpSettings.display_startup_errors = 0 phpSettings.display_errors = 0

bootstrap.path = APPLICATION_PATH "/Bootstrap.php" bootstrap.class = "Bootstrap"

resources.frontController.moduleDirectory = APPLICATION_PATH "/modules" resources.frontController.plugins.debug = "Scienta_Controller_Plugin_Debug"

resources.modules[] =

autoLoaderNameSpaces.0 = "Scienta"

I'm reading the tests for this issue, but don't understand what's the real problem. If I include this revision the application can't run, but if revert to previous everything works.

Thanks in advance. PS: a posibility to show how to configure a modular application with Zend_application and autoad resources?

Posted by Matthew Weier O'Phinney (matthew) on 2009-05-07T03:57:36.000+0000

First, change your autoloaderNamespaces entry to read:

<pre class="highlight">
autoloaderNamespaces[] = "Scienta"

IIRC, numeric keys are not allowed in Zend_Config.

Second, the reason you're not seeing any error messages is because you've told PHP not to display them. Change your display_*errors settings:

<pre class="highlight">
phpSettings.display_startup_errors = 1
phpSettings.display_errors = 1

and this will give you a hint as to any issues you're having.

Third, make sure your error_reporting is as strict as possible. You can do this by adding the following to your config:

<pre class="highlight">
phpSettings.error_reporting = 8191

Do all of the above, and you should get some indicators as to what's occurring.

Posted by Jorge Padron (jpadron) on 2009-05-07T05:20:16.000+0000

Sorry about showing you only the "production" section of my application.ini. "Development" it's the running section that inherits "production" and add this settings:

<pre class="literal">
phpSettings.display_startup_errors = 1
phpSettings.display_errors = 1
phpSettings.error_reporting = 8191

Replaced numeric keys with array notation:

<pre class="literal">
autoloaderNamespaces[] = "Scienta"

The result is the same: the server shutdown without any clue about it (neither apache logs, nor php logs). If I revert the commit everything work again.


Posted by Jorge Padron (jpadron) on 2009-05-07T20:31:03.000+0000

ok, I've found that this error only happens when I have this setting in the ini file:

<pre class="literal"> 
resources.frontController.moduleDirectory = APPLICATION_PATH "/modules"

If I reduce the memory_limit from my php.ini, I get the "memory exhausted" error in Zend/Loader/Autoloader/Resource.php on line 257

that's the unique error I can see, otherwise the server crash.

Posted by Matthew Weier O'Phinney (matthew) on 2009-05-08T04:00:07.000+0000

I can't say I've run into this issue myself, nor heard of any similar reports. Is it possible that you don't have any directories under modules? or that there's a recursive symlink in there?

Posted by Jorge Padron (jpadron) on 2009-05-08T04:44:52.000+0000

First all, thanks for your attention.

I've tried with several environments (including windows OS and Linux) and checked symlinks already. It's a very, very little app without any other logic than test modules autoloader and Zend_Application. If you want to look into, this is the link.

Thanks in advance

Posted by Jorge Padron (jpadron) on 2009-05-09T07:04:31.000+0000


You can find more information in the mailing list: […]

Posted by Chris Martin (cgmartin) on 2009-05-09T21:08:13.000+0000

I am running into this as well (rev 15472).

When using multiple controller directories and Zend_Application_Module_Bootstrap bootstraps it recurses through...

{main}( ) ../index.php:0 Zend_Application_Bootstrap_BootstrapAbstract->bootstrap( ) ../index.php:49 Zend_Application_Bootstrap_BootstrapAbstract->_bootstrap( ) ../BootstrapAbstract.php:518 Zend_Application_Bootstrap_BootstrapAbstract->_executeResource( ) ../BootstrapAbstract.php:558 Zend_Application_Resource_Modules->init( ) ../BootstrapAbstract.php:615 Zend_Application_Bootstrap_BootstrapAbstract->bootstrap( ) ../Modules.php:84 Zend_Application_Bootstrap_BootstrapAbstract->_bootstrap( ) ../BootstrapAbstract.php:518 Zend_Application_Bootstrap_BootstrapAbstract->_executeResource( ) ../BootstrapAbstract.php:558 Zend_Application_Resource_Modules->init( ) ../BootstrapAbstract.php:615 Zend_Application_Bootstrap_BootstrapAbstract->bootstrap( ) ../Modules.php:84 Zend_Application_Bootstrap_BootstrapAbstract->_bootstrap( ) ../BootstrapAbstract.php:518 Zend_Application_Bootstrap_BootstrapAbstract->_executeResource( ) ../BootstrapAbstract.php:558 Zend_Application_Resource_Modules->init( )

...and so on until reaching Fatal error: Maximum function nesting level of '100' reached, aborting!

Posted by Matthew Weier O'Phinney (matthew) on 2009-05-10T04:48:23.000+0000

Jorge, Chris -- that gives me more information. I'm not sure the diagnosis of the issue is correct, but it at least gives me somewhere to start looking. I'll have this resolved for 1.8.1.

Posted by Keith Pope (mute) on 2009-05-10T08:16:27.000+0000

This issue is still present in the rev. 15476

With config of:

[bootstrap] autoloadernamespaces[] = "Zend_" autoloadernamespaces[] = "SF_"

phpsettings.display_errors = 0 phpsettings.error_reporting = 8191 = "Europe/London"

bootstrap.path = APPLICATION_PATH"/bootstrap/Bootstrap.php"

resources.frontcontroller.moduledirectory = APPLICATION_PATH"/modules" resources.frontcontroller.defaultmodule = "storefront" resources.frontcontroller.throwexceptions = false resources.frontcontroller.params.prefixDefaultModule = true resources.frontcontroller.plugins.action = "SF_Plugin_Action" resources.frontcontroller.plugins.admin = "SF_Plugin_AdminContext"

resources.db.adapter = "PDO_MYSQL" resources.db.isdefaulttableadapter = true resources.db.params.dbname = "storefront" resources.db.params.username = "root" resources.db.params.password = "root" resources.db.params.hostname = "localhost" resources.db.params.driver_options.1002 = "SET NAMES UTF8;"

resources.modules[] =

global.autoloadersupresswarnings = true

[production : bootstrap]

[development : bootstrap] phpsettings.display_errors = 1 resources.frontcontroller.throwexceptions = true global.autoloadersupresswarnings = false

[test : bootstrap]

I get recursive loop, this is due to the addition of the call to the parent constructor in the module bootstrap in rev. 15357 this now means that all options are passed back re-adding the resource modules option and causing the loop.

The quick fix is to revert the changes from rev.15357, however I think what actually needs to happen is for the modules option to be removed before it is passed back to the parent.

This issue was previously fixed for ZF-6183 in rev. 14738

I had a quick hack at this by adding this to Zend_Application_Bootstrap_BootstrapAbstract:

<pre class="highlight"> 
    public function removeModulesOption()
        if ($this->hasOption('resources')) {

And then in the module bootstrap:

<pre class="highlight"> 

This however seemed to break my FC plugin that uses the Action Stack???

Hope this helps track this issue down.

Posted by Matthew Weier O'Phinney (matthew) on 2009-05-10T20:23:01.000+0000

I was never able to reproduce the recursion, but I've added in a call to remove the 'Modules' resource within module bootloaders if it is detected.

Posted by Dmitry (prospect) on 2009-05-11T08:01:02.000+0000

I have the same problem. Recursive loop is still present in rev. 15522.

Posted by Jorge Padron (jpadron) on 2009-05-11T08:08:39.000+0000

Here it's solved with r15506 (ZF-6545: merge r15505 to 1.8 release branch)

Posted by Matthew Weier O'Phinney (matthew) on 2009-05-11T08:20:48.000+0000

Dmitry -- I have yet to be able to reproduce the recursion based on any of the information available here or via the referenced mailing lists. I have added logic in the base module bootloader to remove the "Modules" resource during initialization if found, as this was identified by somebody else as the issue.

Please, re-open this issue only if you can post a complete setup that reliably reproduces the issue with current trunk.

Posted by Dmitry (prospect) on 2009-05-11T08:22:29.000+0000

Jorge, don't you really have this problem now? Well, I see the following fixed code in Zend_Application_Module_Bootstrap:

// ZF-6545: prevent recursive registration of modules if ($this->hasPluginResource('Modules')) { $this->unregisterPluginResource('Modules'); } but I still get the recursive loop. If its works fine for you it means I do something wrong...

Posted by Matthew Weier O'Phinney (matthew) on 2009-05-11T08:36:42.000+0000

Dmitry -- is it possible that your module bootstraps are not extending Zend_Application_Module_Bootstrap?

Posted by Tomoaki Kosugi (noopable) on 2009-05-11T10:56:06.000+0000

Incidentally, is it efficient that every Module's Bootstrap constructs Zend_Application_Bootstrap_Bootstrap as parent with the same instance of the application and makes the same resources in them? In this case I supporse the Delegation is better than the Inheritance. Because * Module's Bootstrap should be an inner bootstrap of global bootstrap ,isn't it? * In the case of the Inheritance, The system having many modules should have too many instances of bootstrap.
* If the global bootstrap have resources customized by -- _initFoo -- , they conflict with module's resources.

The Delegation's example,

<pre class="highlight">
interface Zend_Application_Bootstrap_ModuleBootstrapper
 extends Zend_Application_Bootstrap_Bootstrapper
    public function setBootstrap(Zend_Application_Bootstrap_Bootstrapper $bootstrap);

And it must provide properties of the resources with the delegation to the master bootstrap.

Posted by Matthew Weier O'Phinney (matthew) on 2009-05-11T12:00:04.000+0000

@Tomoaki: The application bootstrap could potentially be a module bootstrap instance. As such, having a setBootstrap() instances doesn't make sense -- there is no parent bootstrap.

Second, there will be no conflicts with "global" resources. Each bootstrap is responsible for running its own resources. You can pass these in by prefixing them with the module name, or have your bootstrap grab its own configuration. Any given bootstrap can be responsible for as much or as little bootstrapping as they need.

Third, I don't know what you mean by "too many instances of bootstrap" -- there is one, and then references to that one. (Actually, there will be one for each module, but that's only if the module has a bootstrap, and each module bootstrap is responsible for its own configuration -- which brings us back to the question of what "too many instances" means...)

Posted by Keith Pope (mute) on 2009-05-11T12:35:35.000+0000

Confirmed that this issue is fixed in the trunk now :)

However I have one more issue after the parent::__construct() was added, now my FC plugins are being called twice per request??

My setup is available here:

I have a basic FC plugin which uses the ActionStack this now fails for some reason, and if I echo some text in it in gets called twice instead of once like it should be. If I un-reg the frontcontroller resource everything works as normal:

<pre class="highlight">
        // ZF-6545: prevent recursive registration of modules
        if ($this->hasPluginResource('Modules')) {

I will not reopen this issue but if you could check it out that would be cool :)

Posted by Tomoaki Kosugi (noopable) on 2009-05-11T19:55:58.000+0000


@Matthew In case the module having its bootstrap class and the application having no extra options for the module,the module's bootstrap and the application's bootstrap are as independent bootstrap and they have the same options. Thus Resource_Modules exec the module's bootstrap->bootstrap(). This causes unfortunately conflicts.

For example: This is a scraping of the sequence.

<pre class="highlight">
// application Bootstrap 
class Bootstrap extends Zend_Application_Bootstrap_Bootstrap{
 protected function _initView(){
$view = new Zend_View_Smarty;
// customized code using options 
// and 
// set view to viewRenderer
 return $view;
// Foo Module's Bootstrap
class Foo_Bootstrap extends Zend_Application_Module_Bootstrap{
protected function _initBar(){} //  initializing some.

    $application = new Zend_Application(
            'bootstrap' => '/path/to/Bootstrap.php',
            'resources' => array(
                 'modules' => array(), // to call module bootstrap
                 'view' => array(), // some settings

// Zend_Application exec below
$bootstrap = new Bootstrap($application);

// Resource_Modules exec below
$module = 'Foo';
$bootstrapClass = 'Foo_Bootstrap';
$moduleBootstrap = new $bootstrapClass($bootstrap);
$bootstraps[$module] = $moduleBootstrap;

In this case, setting the view and the viewRenderer by class method - Bootstrap::_initView - . But the module Foo_Bootstrap breaks them unfortunately by a plugin resource so called Zend_Application_Resource_View .-- it creates new view instance and new viewRenderer and push it--. This is the sample of conflicts.

Global resources or static objects have a similar problem. For instance, FrontController resource.

BTW I said "too many instances". In some case the module bootstrap needs the application's resources they have already set. I think that it should be solved by injecting The Application Bootstrap to the module bootstrap. Not by creating new bootstrap instance and making the same resources with the same options.

If the module bootstrap only needs frontController resource , how about this one?

<pre class="highlight">
// Module_Bootstrap::__construct
if ($application instanceof Zend_Application_Bootstrap_Bootstrap) {
 $this->frontController = $application->getResource('FrontController');

Posted by Chris Martin (cgmartin) on 2009-05-11T23:36:46.000+0000

This might be more appropriate as a separate bug, but in case recent changes are related...

Module recursion is fixed, but I am now seeing custom Application Resources being called twice: (r15545)

<pre class="highlight">
class Main_Bootstrap_Resource_View extends Zend_Application_Resource_ResourceAbstract
     * @var Zend_View_Interface
    protected $_view;

     * Defined by Zend_Application_Resource_Resource
     * @return void
    public function init()
        // Return view so bootstrap will store it in the registry
        return $this->getView();

     * Retrieve view object
     * @return Zend_View
    public function getView()
        if (null === $this->_view) {
            $options = $this->getOptions();
            $title   = '';
            if (array_key_exists('title', $options)) {
                $title = $options['title'];

            $view = new Zend_View($options);


"); // Prints twice

            $viewRenderer =
            if (isset($options['viewbasepathspec'])) {
            $this->_view = $view;
        return $this->_view;

<pre class="highlight">

Posted by Matthew Weier O'Phinney (matthew) on 2009-05-12T05:39:24.000+0000

@Chris Martin: I think what you are seeing is related to what @Tomoaki is indicating -- that the module bootstrap is running the same plugin resources as the application bootstrap. I'm going to get this resolved for 1.8.1 today.

Posted by Matthew Weier O'Phinney (matthew) on 2009-05-12T06:53:46.000+0000

@Tomoaki -- I've updated the code to (a) no longer call parent::__construct() (@Chris, @Keith -- this was the culprit behind duplicate resource initialization), and also to ensure the front controller resource is registered (which ensures a module bootstrap can run standalone if necessary).

Have you found an issue?

See the Overview section for more details.


© 2006-2018 by Zend, a Rogue Wave Company. Made with by awesome contributors.

This website is built using zend-expressive and it runs on PHP 7.