Comments

Posted by old of Satoru Yoshida (yoshida@zend.co.jp) on 2009-01-02T16:33:20.000+0000

Set component

Posted by Darby Felton (darby) on 2009-01-09T06:05:38.000+0000

I don't experience this problem with version 1.7.2 of Zend_Amf_Server. I can call setClass(), passing it an object with no namespace, and I get no such error. I think this issue may have been resolved.

<pre class="highlight">
Warning: strrpos() expects parameter 1 to be string, object given in /Users/norm2782/Projects/OSS/ZF/standard/trunk/library/Zend/Amf/Server.php on line 501
Catchable fatal error: Object of class MyService could not be converted to string in /Users/norm2782/Projects/OSS/ZF/standard/trunk/library/Zend/Amf/Server.php on line 501

It does not look like a unit test was written for this. Please don't mark an item as resolved without a corresponding unit test that tests the new feature.

Posted by Wade Arnold (wadearnold) on 2009-01-09T07:16:17.000+0000

Also do either of you have a use case for this that you could help me understand so that I can use it in the documentation as to why you would pass an instantiated object through setClass(). Thanks for the code submission and making Zend Amf better for everyone! Really appreciate the help!

The primary use case for this is that Zend_Server_Reflection supports reflecting on an object. Because of this, it's better to have Zend_Amf_Server support this as well, because otherwise it would be unexpected behavior.

Posted by Wade Arnold (wadearnold) on 2009-01-09T07:31:01.000+0000

Awesome thanks!

Posted by Darby Felton (darby) on 2009-01-09T10:36:36.000+0000

Sorry, I wasn't using latest trunk version but the version included with 1.7.2. This issue says that it affects 1.7.2, but I can't see that it does.

When the object passed as argument is an instance of a class whose constructor requires arguments, an instantiation error is raised on service call. I'm using 1.7.6 version of ZF. I've done some debug and found that in Zend/Amf/Server.php on line 165 (_dispatch method) the method's declaring class obtained by reflection is called on a NEW instance created with default construction and not on the object passed to setClass() as I expected. This behavior seems to raise the instantiation trouble I've mentioned; moreover, this behavior seems to be inconsistent w.r.t. the one observed, for example, in Zend/Json/Server component.