ZF-6974 is marked as resolved, but this issue is still presenting in the trunk for me.

The problem occurs because Zend_Application_Bootstrap_BootstrapAbstract::getPluginResourceNames() calls Zend_Application_Bootstrap_BootstrapAbstract::getPluginResources() which in turn calls Zend_Application_Bootstrap_BootstrapAbstract::_loadPluginResource(). This instantiates but does not execute instances of the registered resource objects, causing Zend_Application_Resource_Session::setSaveHandler() to instantiate an instance of Zend_Db_Table_Abstract before the Db resource is actually executed. Since Zend_Application_Resource_Db doesn't call Zend_Db_Table::setDefaultAdapter() until it's init() method is called, the desired behavior fails.

The simplest solution seems to be to remove the call to getPluginResources() in Zend_Application_Bootstrap_BootstrapAbstract::getPluginResourceNames(). This seems to be working for me, but may cause problems, so another solution may be more desirable. In any case, this bug will definitely cause problems with other resources down the line and should be fixed up.

I think it should call bootstrap("db"), if the Db-Savehandler is used, because its a direct dependency and the manual mention, that dependencies should be solved this way. Maybe the savehandler-class call it itself, instead of the session-pluginresource.

I disagree Sebastian. Technically Zend_Application_Resource_Session is not dependent on Zend_Application_Resource_Db, so I don't think we should force this in the code.

If we wanted to focus the solution within the Zend_Application_Resource_Session class, we could think about restructuring things so the save handler instance, in this case an object of Zend_Db_Table_Abstract, isn't created until Zend_Application_Resource_Session::init() is called. In fact, I don't see why we can't move all of the logic in Zend_Application_Resource_Session::setSaveHandler() to Zend_Application_Resource_Session::init().

However, as I noted above, the problem we are encountering is tied to the way resources are setup, loaded, and executed, so it may be best to tackle the underlying logic to prevent future bugs with different resources.

{quote}I disagree Sebastian. Technically Zend_Application_Resource_Session is not dependent on Zend_Application_Resource_Db, so I don't think we should force this in the code. {quote}
Not the whole resource, but the Db-savehandler.

Yes, but Zend_Session_SaveHandler_DbTable isn't dependent on Zend_Application_Resource_Db either. It's a subclass of Zend_Db_Table_Abstract and must have an instance of Zend_Db_Adapter_Abstract set as it's adapter, but that adapter doesn't need to be created through an application resource.

Posted by Vladimir Michailenko (mich) on 2009-07-23T15:14:01.000+0000

Moved SaveHandler initialization from setOptions() to init() method (db should be initialized at this point).

Posted by Alexandre Nault (anault) on 2009-07-23T19:28:31.000+0000

This patch works for me!

Thank you for it.

Issue ZF-7168 resolved with the patch

Posted by Benjamin Eberlei (beberlei) on 2009-09-17T15:13:44.000+0000

Applied the patch and wrote a unittest suite for Session resource, merged into 1.9 release branch.