ZF-6455: Zend_Application allows loading 2 configs and disallow module bootstrap "config"


I dont know, if its really a issue. To me it seems a strange behaviour, but its at least an undocumented feature ;)

        if (null !== $options) {
            if (is_string($options)) {
                $options = $this->_loadConfig($options);
            } elseif ($options instanceof Zend_Config) {
                $options = $options->toArray();
            } elseif (!is_array($options)) {
                throw new Zend_Application_Exception('Invalid options provided; must be location of config file, a config object, or an array');


if $options is a string, the config will be loaded from file and then given to setOptions().

        if (!empty($options['config'])) {
            $options += $this->_loadConfig($options['config']);

If there is a key 'config' in the file Ive loaded before, setOptions() tries to load a second config file.

On the other hand, if there is a module 'config' with a module-bootstrap, its not configurable, because Zend_Application finds the key 'config' and tries to load ... something.



The other predefined values 'includepaths', 'autoloadernamespaces', 'bootstrap', 'resources' and so on are also not useable as modules with module-bootstrap.

Version is trunk rev 15242


Matthew, I'd suggest a "module" key in the root options which childs are handled like module bootstrap options in the parent. The current way of defining module specific bootstrap options should stay, but this one would be a fallback which can be used when somebody has modules which conflict with our reserved keys.

I would like to see the this :)

Meanwhile I found, that the other behaviour -- the "second config file" -- is quiet useful, even if its only useable, when the second constructor argument is a string. This allows something like this



Currently its not working as expected caused by another bug:

The actual idea behind the config option-key was, that you can specify specific options via an array, but additionally load a config file. But nice that it also finds other useful cases.

If you pass an array to the constructor the "hack" wont work, because it load a config file only once (in _loadConfig()). It can confuse somebody, if he will change a string-to-a-file to a array later and wondering, that the "additional file" is not loaded anymore.

My question is why are You working with arrays not objects? I think _loadConfig() should additionally write protected $_config variable with reference to loaded $config or return merged data. Currently there is no way to get configuration file in it's original state - there is only getOptions() method with options already transformed to array. I think some of us might need this for further prcoessing and pushing data:

protected function _initConfig() {
    $config = new Zend_Config($this->getOptions());
    Zend_Registry::set('config', $config);

back to Zend_Config is really stupid.

We're using arrays as it makes it easier to do comparisons, and to manipulate the keys in order to do comparisons; additionally, it offers better compatibility throughout various framework components.

First, in Zend_Application, keys are case insensitive. However, because Zend_Config uses object properties, the keys are case sensitive. This makes it difficult, if not impossible, to test accurately for the existence of given keys. As a result, in our tests, we found there were many cases where existing keys were simply not matched. Casting to an array and storing as an array internally ensures we can transform those keys and do case insensitive matching.

Second, many framework accept an array of options to the constructor and/or a factory. Many also accept Zend_Config objects, but in all such cases, also accept arrays. It's thus easier to simply cast to an array within Zend_Application, as the arrays will be able to be used with any component.

Finally, the reason that you can pass a "config" key to the Zend_Application options is to allow you to provide local overrides of the keys in your configuration file. These are, clearly, going to be passed as an array -- which means that any value in $_config as you propose would be non-representative of the actual configuration.

Bulk change of all issues last updated before 1st January 2010 as "Won't Fix".

Feel free to re-open and provide a patch if you want to fix this issue.