Problem happens if listener has depends on @doctrine.orm.entity_manager (even in case of deep dependency)

    test_listener:
        class: TestListener
        arguments: [@doctrine.orm.entity_manager]
        tags:
            - { name: doctrine.event_listener, event: prePersist }

if anyone else was struggling to spot the 'bug', addEventSubscriber and addEventListener are after the return

@sirian Why do you even want to inject the entity manager?

As you can see here, you can get the entity manager from LifecycleEventArgs. http://symfony.com/doc/current/cookbook/doctrine/event_listeners_subscribers.html#creating-the-listener-class

If I am trying to reproduce I am getting a circular reference error.

@peterrehm it is simplified example. more complex:

    foo: 
        class: Foo
        arguments: [@doctrine.orm.entity_manager]

    test_listener:
        class: TestListener
        arguments: [@foo]
        tags:
            - { name: doctrine.event_listener, event: prePersist }

@sirian This is a circular reference. This object graph requires to instantiate the entity manager before instantiating Foo, and to instantiate Foo before the TestListener. But the TestListener needs to be instantiating when building the doctrine EventManager required by the EntityManager. And here, you see the issue: where can we start instantiating ? nowhere.

@stof But in any case no code should be generated after a return statement, or what do you think?

yes, there is indeed a bug in the code generation.

@stof Should a separate issue be opened? What would be the expected result? If it is that circular reference, it should throw an exception?

@sirian I was solving that issue once with injecting the event dispatcher to the listener and do such specific action based on an event like user.create. That might solve your issue with some refactoring.

@peterrehm yes, circular references should throw an exception

@stof as i remember same problem happened even with calls:

    foo: 
        class: Foo
        calls:
            - [setEntityManager, [@doctrine.orm.entity_manager]]

    test_listener:
        class: TestListener
        arguments: [@foo]
        tags:
            - { name: doctrine.event_listener, event: prePersist }

@sirian I think the only way is to actually refactor. Which type of injection should in this case not matter.

@peterrehm yes, i refactored code in the same day.
But it was difficult to find reson why event listeners didn't work.
So pls add throwing circular reference exception)

@sirian injecting through a setter is still a circular reference (the only case where setter injection can workaround a circular reference is when the inlining of private services brings everything back into the same service instantiation)

I ran into this yesterday as well and it took forever to figure out why statements were being written after the return statement.

Which version of Symfony are you using? #7699 might have solved the issue, but it was merged a while ago.

@fabpot 2.3.4 for me

@dragonwize Can you fork the Symfony StandardEdition and modify the configuration in a way to reproduce the error? That would help me spot the bug and fix it. Thanks.

@fabpot I have just done this. @dragonwize you don't need to work on this.

If you just clear the cache you will have this in the dumped file:

protected function getDoctrine_Dbal_DefaultConnectionService()
{
    $a = new \Doctrine\DBAL\Logging\LoggerChain();
    $a->addLogger(new \Symfony\Bridge\Doctrine\Logger\DbalLogger($this->get('monolog.logger.doctrine', ContainerInterface::NULL_ON_INVALID_REFERENCE), $this->get('debug.stopwatch', ContainerInterface::NULL_ON_INVALID_REFERENCE)));
    $a->addLogger($this->get('doctrine.dbal.logger.profiling.default'));

    $b = new \Doctrine\DBAL\Configuration();
    $b->setSQLLogger($a);

    $c = new \Symfony\Bridge\Doctrine\ContainerAwareEventManager($this);

    return $this->services['doctrine.dbal.default_connection'] = $this->get('doctrine.dbal.connection_factory')->createConnection(array('dbname' => 'sf2_test', 'host' => '127.0.0.1', 'port' => NULL, 'user' => 'root', 'password' => NULL, 'charset' => 'UTF8', 'driver' => 'pdo_mysql', 'driverOptions' => array()), $b, $c, array());
    $c->addEventListener(array(0 => 'prePersist'), $this->get('acme.demo.doctrinelistener'));

}

I hope this helps you.

@peterrehm thx

@fabpot As mentioned above as well, while the example @peterrehm has given shows the issue in a simple way, it happens even when the entitymanager is passed into dependent argument of the service. In my case it was 3 services deep and so it was not immediately obvious that it was a circular dependency.

@dragonwize What do you mean with 3 services deep? Still an EventListener? I guess if the simple example is going to be fixed, yours should be fine as well...

@peterrehm Yes the fix should most likely fix both at the same time. In my case I had a custom service that used the entity manager and another service that required that service and it was what was being passed into my doctrine event subscriber.

Once you see it, it is obviously a circular issue but in can be very difficult to figure that part out so if there is a way to throw an exception on it, I think that is fine.

Can you test the fix in #8999?

@fabpot In my sample the exception is now detected:

[Symfony\Component\DependencyInjection\Exception\ServiceCircularReferenceException]
Circular reference detected for service "doctrine.dbal.default_connection", path: "doctrine.dbal.default_connection".