ZF-11161: RegisterErrorHandle not work with Xml formatter
Description
If I call the Registererrorhandle Zend_Log with the xml formatter its not works and give error
If I call the Registererrorhandle Zend_Log with the xml formatter its not works and give error
Comments
Posted by Benoît Durand (intiilapa) on 2011-03-13T14:36:18.000+0000
@Fabio, Can you provide a code to reproduce your problem?
Posted by Fabio Ginzel (fabioginzel) on 2011-03-15T19:45:28.000+0000
Application.ini:
Posted by Fabio Ginzel (fabioginzel) on 2011-03-15T19:46:00.000+0000
error:
Fatal error: Uncaught exception 'DOMException' with message 'DOMElement::__construct() expects parameter 2 to be string, array given' in D:\Sistemas\sas\sne_inscreve_evento\library\Zend\Log\Formatter\Xml.php:152 Stack trace: #0 D:\Sistemas\sas\sne_inscreve_evento\library\Zend\Log\Formatter\Xml.php(152): DOMElement->__construct('context', Array) #1 D:\Sistemas\sas\sne_inscreve_evento\library\Zend\Log\Writer\Stream.php(131): Zend_Log_Formatter_Xml->format(Array) #2 D:\Sistemas\sas\sne_inscreve_evento\library\Zend\Log\Writer\Abstract.php(85): Zend_Log_Writer_Stream->_write(Array) #3 D:\Sistemas\sas\sne_inscreve_evento\library\Zend\Log.php(428): Zend_Log_Writer_Abstract->write(Array) #4 D:\Sistemas\sas\sne_inscreve_evento\library\Zend\Log.php(594): Zend_Log->log('Undefined varia...', 5, Array) #5 D:\Sistemas\sas\sne_inscreve_evento\application\Bootstrap.php(10): Zend_Log->errorHandler(8, 'Undefined varia...', 'D:\Sistemas\sas...', 10, Array) #6 D:\Sistemas\sas\sne_inscreve_evento\library\Zend\Application\Bootstrap\BootstrapAb in D:\Sistemas\sas\sne_inscreve_evento\library\Zend\Log\Formatter\Xml.php on line 152
Posted by Adam Lundrigan (adamlundrigan) on 2011-04-30T16:12:18.000+0000
@Fabio I have been able to reproduce your issue. I created a stock Zend Framework project using Zend_Tool:
Then applied the following changes to add logging to the application (following instructions here: http://framework.zend.com/manual/en/…):
When I open up my web browser and go to /test I see the output of the error handler controller and the following entry in data/logs/application.log:
Then I patched Zend_Log_Formatter_Xml to cast the argument to DOMElement to string, like so:
And everything now works as expected: When visiting /test in a web browser you see the proper view script, and the application.log file contains:
All tests in Zend_Log test suite still pass after applying my fix.
Posted by Adam Lundrigan (adamlundrigan) on 2011-04-30T16:22:43.000+0000
Fixed in trunk r23905
Posted by Satoru Yoshida (satoruyoshida) on 2011-05-03T10:27:11.000+0000
Hello, Adam. I will push [solve] button as proxy for You. If You want to release at next mini, You can merge this commit fron trunk to 1.11 branch.
Thanks.
Posted by Satoru Yoshida (satoruyoshida) on 2011-05-03T15:01:31.000+0000
Fixed 1.11 branch at 23957
Posted by Ralph Schindler (ralph) on 2011-05-03T19:02:06.000+0000
Reopened. Backed out r23905 from trunk in r23980 Backed out r23957 from release branch 1.11 in r23981
Posted by Benoît Durand (intiilapa) on 2011-05-04T17:31:37.000+0000
I have a problem with the commit r23905. Yes, it solves the fatal error, but the behavior is wrong. A context with the error handler is always an array. I think the formatters, and writers can't support array for context. It's related to the problem of array in ZF-10427 for extra info when you use the simple formatter.
I recommand to delete the optional parameter errcontext of the method Zend_Log::errorHandler().
Why do you need more info than standard display with the context? Just to remind you, the context contains every variable in the scope.
Posted by Adam Lundrigan (adamlundrigan) on 2011-05-04T17:52:57.000+0000
Benoît,
Thanks for summarizing our IRC chat from yesterday....I hadn't had a chance to do that yet :P
I completely agree. my patch was intended to prevent Zend_Log_Formatter_Xml::log from throwing a fatal error when non-string data was passed along to DOMElement. What you've described above better treats the source of the problem rather than just the symptom. Based on that, this is what I suggest"
In my opinion, this adequately treats the source of the problem (context data passed to the formatters, which can't handle it) while maintaining backwards compatibility (not changing the errorHandler() method signature and still passing $errcontext along to the original error handler (see Zend/Log.php:598))
Do you think this is an adequate solution? Are there any existing formatters which might want access to 'context'?
Posted by Adam Lundrigan (adamlundrigan) on 2011-05-04T22:49:10.000+0000
I've been thinking about this some more, and I think a better solution would be to modify the behavior of the existing formatters which are unable to handle the context attribute to ignore it: * Firebug: Already covered, as context isn't included in it's output * Simple: Already covered, as context isn't included in it's output * Xml: Requires simple modification to ignore context:
I chose to still cast $value to string, as that's what DOMElement constructor expects.
This solution solves the issue at hand, as well as still allowing future (or user-created) formatters to use the context element if they see fit.
Comments?
Posted by Benoît Durand (intiilapa) on 2011-05-06T18:04:18.000+0000
People can already use the key context with Zend_Log::setEventItem() method. So, potential bc imao.
Posted by Adam Lundrigan (adamlundrigan) on 2011-05-24T00:35:20.000+0000
Good point. How about this as an alternate implementation?
This excludes an non-empty, non-scalar value from being included in the formatted output.
Posted by Chl (chl) on 2011-05-26T19:14:02.000+0000
Hello,
in my case, I quite needed some informations in the $value (which was a POST with a subform). Could we try this ?
Posted by Adam Lundrigan (adamlundrigan) on 2011-05-28T17:03:46.000+0000
@Chl:
That would assume the user of the log - be it a person or a parsing program - understands PHP serialization and can deserialize the value. My perspective is that the built-in log formatters should be simple, with more complex formatting needs implemented by the application to fit it's own use case.
The purpose of this issue, and the suggested fix, are only aimed at solving the issue at hand: usage of the XML formatter causes an exception to be raised. Discussions regarding changes to what the formatter outputs should be undertaken in a dedicated issue, on IRC, or on the mailing list.
Posted by Adam Lundrigan (adamlundrigan) on 2011-05-29T00:47:59.000+0000
Fixed in trunk r24079 I've committed the patch suggested on 24/May/11 (exclude non-empty, non-scalar values from being included in the formatted output) Hoping that 2nd time is the charm ;)
Posted by Benoît Durand (intiilapa) on 2011-05-29T14:36:04.000+0000
@Chl I agree with Adam. @Adam Why are you excluded the empty value? It sounds like a little BC.
Posted by Adam Lundrigan (adamlundrigan) on 2011-05-29T14:57:56.000+0000
@intiilapa. Sorry, my initial wording was clumsy. The patch permits only empty and scalar values to be passed on to DOMElement.
Posted by Adam Lundrigan (adamlundrigan) on 2011-06-07T23:12:16.000+0000
Merged to release-1.11 in r24128
Posted by Martin (z3ndm@rt!n) on 2011-07-11T21:04:12.000+0000
This fix breaks functionality as described in the manual. When passing an exception to the log, the message is ignored.
The reason for this is the check on line 149 of Zend_Log_Formatter_Xml which uses www.php.net/is_scalar" rel="nofollow">is_scalar() to check if the message has to be added to the log. An Exception object is not a scalar and is therefore ignored.
Possible fix: replace:
Posted by Matthew Weier O'Phinney (matthew) on 2011-07-13T18:22:37.000+0000
Opening due to comment activity
Posted by Matthew Weier O'Phinney (matthew) on 2011-07-13T18:23:23.000+0000
Added test that uses serializable object in event, and "applied" patch from Martin for testing for objects with __toString prior to rendering.