Description

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.

Comments

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.

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.

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:

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...

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.

@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??

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:

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

Thanks,

@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.

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?

@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.

@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).