Bug #28638

Signals can't be defined in abstract classes

Added by Bastian Waidelich about 10 years ago. Updated almost 10 years ago.

Status:
Resolved
Priority:
Should have
Assignee:
Category:
AOP
Start date:
2011-08-01
Due date:
% Done:

100%

Estimated time:
PHP Version:
Has patch:
Complexity:

Description

The AOP ProxyClassBuilder produces invalid code when signals are defined in an abstract class.

Steps to reproduce:

AbstractSignalTest.php
<?php
namespace Foo\Bar;
abstract class AbstractSignalTest {

    public function testSignal() {
        $this->emitTestSignal();
    }

    /**
     * @signal
     */
    public function emitTestSignal() {}
}

?>

SignalTest.php
<?php namespace Foo\Bar; class SignalTest extends AbstractSignalTest { } ?>
In some controller:
$signalTest = new \Foo\Bar\SignalTest(); $signalTest->testSignal();

Result:

#1: Notice: Undefined index: emitTestSignal in Development\Cache\Code\FLOW3_Object_Classes\Foo_Bar_AbstractSignalTest.php line 98

The problem is, that the proxy code tries to access $this->FLOW3_AOP_Proxy_targetMethodsAndGroupedAdvices which is declared private.

#1

Updated by Mr. Hudson about 10 years ago

  • Status changed from Accepted to Under Review

Patch set 1 of change I6480321c117dc0eb264fda45a952d27505156f82 has been pushed to the review server.
It is available at http://review.typo3.org/3971

#2

Updated by Bastian Waidelich about 10 years ago

  • Priority changed from Should have to Must have
#3

Updated by Sebastian Kurfuerst about 10 years ago

  • Priority changed from Must have to Should have
#4

Updated by Robert Lemke about 10 years ago

  • Target version changed from 1.0 beta 1 to 1.0 beta 2

As far as I can see, the problem is not limited to just signals, but any advised method of an abstract class. If so, we should rephrase / rename this issue.

#5

Updated by Robert Lemke about 10 years ago

  • Target version changed from 1.0 beta 2 to 1.0.0
#6

Updated by Mr. Hudson about 10 years ago

Patch set 2 of change I6480321c117dc0eb264fda45a952d27505156f82 has been pushed to the review server.
It is available at http://review.typo3.org/3971

#7

Updated by Bastian Waidelich about 10 years ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100
#8

Updated by Christopher Hlubek about 10 years ago

I have some kind of a regression with this after further testing (didn't notice this at first):

If a class uses a magic __call method to handle dynamic function calls, a is_callable('parent::FLOW3_AOP...') will always return TRUE, such that an object receives a call with FLOW3_AOP_Proxy_buildMethodsAndAdvicesArray. This could be misleading and caused problems with the SOAP package for me. A quick fix is to filter such method calls (e.g. starting with "FLOW3_AOP") inside a custom "__call" method, but I consider this a quick hack and not a long-term solution.

Can we detect somehow, that a parent really has this method during compilation (e.g. reflection)?

#9

Updated by Christopher Hlubek about 10 years ago

  • Status changed from Resolved to Needs Feedback
#10

Updated by Bastian Waidelich about 10 years ago

  • Assignee changed from Bastian Waidelich to Robert Lemke
#11

Updated by Karsten Dambekalns almost 10 years ago

  • Status changed from Needs Feedback to Resolved
#12

Updated by Karsten Dambekalns almost 10 years ago

The regression has been fixed with Icf6bdf3f789162afbca61d7cf915dbb7ecd583d5 (https://review.typo3.org/#change,5409)

Also available in: Atom PDF