Zend AMF throwing InvocationTargetException - php

I am trying to make a service call to a php function from flex, through Zend AMF. Most of the functions get called fine, but for one particular function, it throws the following exception:
InvocationTargetException:There was an
error while invoking the operation.
Check your operation inputs or server
code and try invoking the operation
again.
Reason: Fatal error: Call to a member
function getInvokeArguments() on a
non-object in
D:\wamp\www\ZendFramework\library\Zend\Amf\Server.php
on line 328
I am not able to debug through this - has anyone faced any issue like this before, or have any ideas how this can be debugged?

At a quick glance through ZFW's source, this appears to be a bug on their framework.
// There is no check if $this->_table[$qualifiedName] is an object, implements an interface, extends a class, only if it's set (the key exists).
$info = $this->_table[$qualifiedName];
$argv = $info->getInvokeArguments(); // Here's when you get the error.
Source: http://framework.zend.com/code/filedetails.php?repname=Zend+Framework&path=/trunk/library/Zend/Amf/Server.php
I looked in their bug tracker and haven't found anything related to this, perhaps you should open a new issue?
Additionally, you can debug the problem by grabbing the message that Flex is sending to the PHP client and making a test case out of it.

We finally realized that this was a problem in the flex project setup - don't know exactly what it was, but once we deleted and created the project again, things started working fine!

Related

The Bug Genie 'undefined function make_url()'

PHP Fatal error: Call to undefined function thebuggenie\core\helpers\make_url() in ../core/helpers/TextParser.php on line 706
This is the error that I keep getting when trying to set up the VCS-integration successfully in The Bug Genie. It is an issue tracker that has VCS (git) integration. The commits can be linked to a project, and with the correct commit-message to the right issue using a git-hook. Then you can view the commit in the issue tracker. Apparently the commit is getting linked to the project, but it doesn't get linked to the issue because of the error. Can anybody help me?
The source code on GitHub.
Thanks in advance!
I've found the solution. There appears to be an error in the vcs-integration. Apparently the ui.inc.php-library is not loaded when using the git-hook.
So the temporary solution (until they solve it) is:
At modules/vcs_integration/Vcs_integration.php:226, add:
framework\Context::loadLibrary('ui');
As far as i see, make_url function is defined in a global namespace, but is called from namespace thebuggenie\core\helpers. So i suppose that's your problem

Console calls (like cache clears or behat) throw an exception but all is fine in browser

I am creating a Symfony2 application, all works well, but when i try to execute my behat tests or clear the cache, i got this error:
Error: Call to undefined method
Symfony\Bundle\FrameworkBundle\Templating\Loader\TemplateLocator::isFresh() in
[...]/vendor/symfony/assetic-
bundle/Symfony/Bundle/AsseticBundle/Factory/Resource/FileResource.php line 49
TemplateLocator does not even implements LoaderInterface, as required in FileResource construct.
Anyone has a clue ?
I figured out where the problem came from, but without understanding it.
It appeared that somewhere in my application I called
$this->container->get('twig')->render("Bundle:View:action.html.twig")
I changed to
$this->container->get('templating')->render("Bundle:View:action.html.twig")
twig service is a Twig_Environment instance, and template is a DelegatingEngine instance, both allowing to render a template.
And all works great again.
If someone could explain me what happened, I'll appreciate :)

Symfony2 PHPUnit, slightly long test, fatal error related to Monolog

I have narrowed my problem down to a single unit-test which involves a pretty clean dbal query. The query involves a nestedsets and the failure occurs when I go from 3 to 4 levels of hierarchical categories. Very little changes in terms of execution time.. And the functionality I'm work with has no problem at 10 level. However, in PhpUnit when I run the test with 4 or more levels -- I get a fatal error.
*To summarize, a query that may take a split second more than usual OR a tab bit more resources is getting me a php fatal error in PHPUnit *
And the Error Looks like this:
Fatal error: Call to undefined method Monolog\Formatter\LineFormatter::stopEvent() in /var/www/my-app/vendor/symfony/symfony/src/Symfony/Component/HttpKernel/Debug/Stopwatch.php on line 92
Someone here had a phpUnit fatal error problem on line 92 as well. Could it be related??
I've listed some quirky ways (below) to bypass my problem but I'd still like to know why such a basic test seems to be causing this problem.
Run PhpUnit with processIsolation set to "true".
Don't access the static::createClient(); in the setUpBeforeClass() method
I've had a respected member of #symfony (Stof) suggest that it looks like I'm improperly DI'ing #logger into a service.. but I've confirmed this doesn't seem to be the by taking the logger service out of any of my services.
Maybe this issue has something to do with a timeout? (The error mentions stopevent and stopwatch). Or maybe this error has something to do with accessing $client = static::createClient(); in setUpBeforeClass().. and then accessing is again in preceding tests.. Regardless.. it's confusing me and as far as I can tell, everything else in my Symfony2 (2.1.1) installation is working perfectly fine.
* LINE 92 of Stopwatch.php .. github source file here *
/**
* Stops an event.
* #param string $name The event name
* #return StopwatchEvent A StopwatchEvent instance
*/
public function stop($name)
{ return end($this->activeSections)->stopEvent($name);}
OK. So you grab the last item from the $this->activeSections array and they try to run the stopEvent() method on it. It would seem in this case that the LineFormatter class does not have that method available to it.
I am not familiar with Monolog, but in a brief glance at their latest GitHUb repo, I can see that neither the LineFormatter or NormalizerFormatter class which it inherits from have such a method.
It seems like Monolog is not playing nice with Symfony. And that without modifying Monolog and/or the Symfony Stopwatch class, you will not be able to use Stopwatch to profile your Monolog-related code.

PHP-Yii: Using Yiis logger when a request is not completed due to php level error

This is probably a yii specific question, even though I wouldn't surprised if experienced non-Yii we developers will be also able to contribute.
I often encounter the following situation:
My application fails due to a fatal error on the php level. Something like $var->property when $var==null
I want to understand how $var came to be ==null.
I'd use logs for this, however, problem is that no logs are left when a request is ended due to php error.
edit: this only happens for fatal errors. For other php errors I have my logs back
An example:
For
$nonExistingVar->someProperty;
I do have my logs recorded, as it yields PHP Error Undefined variable: nonExistingVar
However, if I do define the variable and set it to null,
$tmp = null;
$tmp->prop;
Then I loose the logs, as it results in "Fatal error: Call to a member function hasErrors() on a non-object"
Does anybody understand why does it happen? And how can the logger be anyway used in this situations? I tried setting autoFlush=1, doesn't help
Thanks
Gidi
The below allowed me to have my logs even on fatal errors:
function yiiCorrectShutdown()
{
Yii::app()->end();
//the following line will work as well
//Yii::app()->log->processLogs(null);
}
register_shutdown_function('yiiCorrectShutdown');
I wrote an extension class that logs in real-time thus avoiding any need to modify flow paths. I posted it here on the Yii Wiki

Fatal error with Custom Magento Module on one server but not the other

I am creating my own custom module in Magento and during testing on a Litespeed server (PHP v5.2.14) I am getting a Fatal Error: Call to a member function batch() on a non-object in ../../../BatchController.php on line 25 that was not appearing during testing on another linux server and a wamp server (PHP v5.2.11).
This one has stumped me. I am guessing it has something to do with the server configuration rather than the code itself. But i am just guessing. I was hoping someone here could tell me.
The only real major difference I could see, aside from the php versions and environment, is that the server that the error is on is using the Suhosin Patch. But would that be something that could cause this?
The line in question is Mage::getModel('mymodule/mymodel')->batch(); which is enclosed in an IF statement. batch() is a public function located in my model file.
If you need more code let me know.
Thanks!
If you get a "non-object" error when calling a model, there's a problem with Magento's attempt to get your model class, and it is returning null. The reasons for this are not always apparent. If this worked identically on a normal LAMP stack, then the problem is most likely not in your code.
My first guess would be that the file does not have the proper permissions. Otherwise, it may have to do with resolving the classname. You could test this temporarily by calling the plugin directly like this:
$obj = new Mynamespace_Mymodule_Model_Mymodel();
$obj->batch();
If this works, then the file is readable, and you will want to go spelunking in the resolution of that classname. If it doesn't work, you have a problem with either autoloading or the declaration of your class.
Hope that helps!
Thanks,
Joe
Break it down.
You've tried to call
Mage::getModel('mymodule/mymodel')->batch();
and PHP told you it tried to call the method batch on a non-object. That means
Mage::getModel('mymodule/mymodel')
isn't returning a Model object the way it's supposed to.
First thing to do is clear out your Magento cache on the server you're having problems with. If your Module's config hasn't been loaded into the global config tree Magento will try to instantiate a Mage_Core_Model_Mymodel, and fail.
Second step is to make sure your module's app/etc/module file is in place.
Third step is to add some debugging (assuming a 1.4 branch) to the method that instantiates your objects and determine why Magento can't create your object
File: app/code/core/Mage/Core/Model/Config.php
...
public function getModelInstance($modelClass='', $constructArguments=array())
{
$className = $this->getModelClassName($modelClass);
if (class_exists($className)) {
Varien_Profiler::start('CORE::create_object_of::'.$className);
$obj = new $className($constructArguments);
Varien_Profiler::stop('CORE::create_object_of::'.$className);
return $obj;
} else {
#throw Mage::exception('Mage_Core', Mage::helper('core')->__('Model class does not exist: %s.', $modelClass));
return false;
}
}
...

Categories