|
|
|
This is actually the intended behavior.
In fact, Zend_Loader shouldnt be throwing warnings or errors, and there is a new verison in the incubator that supresses those issues. I'm gonna wait on this. – Updating project management info. I found the same problem. Have a custom savehandler, which uses Zend_XmlRpc_Client. This somewhere down the chain uses Zend_Validate_Hostname and for a .com address it tried to do Zend_Loader::isReadible("Zend/Validate/Hostname/Com.php"), which does not exist. isReadible tried to @fopen and surpress the warning when it does NOT exist. Which is fine, except the above error handler seems to ignore the "@" in front of the fread.
This renders Zend_XmlRpc_Client unusable within a session savehandler callback !! ZF 1.5.2 that is. and php 5.2.1 through php 5.2.6 is what I tried. I when through all possible php.ini settings, but could not figure out how to make Zend_Session::start() respect the @ in Zend_Loader. Any glue? I've been looking into
The underlying problem is that if a custom error handler is used then this will always receive errors, even when they are suppressed. The solution is to update the code in Zend_Session_Exception::handleSessionStartError as so: static public function handleSessionStartError($errno, $errstr, $errfile, $errline, $errcontext) { // Do not throw an exception if this is a suppressed error - see ZF-3020 if (error_reporting() === 0) { return; } self::$sessionStartError = $errfile . '(Line:' . $errline . '): Error #' . $errno . ' ' . $errstr . ' ' . $errcontext; } I can make this change myself if given SVN commit rights to the Zend/Session folder best wishes, WHAT THE F^H^H^H^H^H^H^H^H^H^HI would really appreciate it if this were fixed.
To add more information to my previous outburst,
Warning: array_key_exists() [function.array-key-exists]: The first argument should be either a string or an integer in /usr/lib64/php/ZendFramework-1.7.1/library/Zend/Filter/Input.php on line 429 Fatal error: Exception thrown without a stack frame in Unknown on line 0 Disappears when Zend_Session::start() is commented out. Thanks Ralph (sigh) Sorry, everyone. It turns out it was my own dumb fault. There was a bug in our custom save handler. After two hours trying to debug this, my eyes were going cross-eyed. My apologies.
So is the 1.8 suppress warnings going to fix this? And is there any chance of it being fixed in the 1.7 branch? I've hacked ZendSession to get around this which I hate doing, but this bug is a royal pain.
I'm using Doctrine with ZF, and doctrine does a lot of on the fly class generation. Zend autoloader tries to load these classes when it doesn't need to, however I can easily suppress these warnings by setting error reporting and the app works great. That is, until I try to save a Doctrine object in the session. Since Zend Session believes that I don't know what I want my error reporting to be and throws an exception for every little warning or notice, it will grind the app to a halt for a problem that I've configured the app to ignore. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
ZF-1325is the source of this issue.