12

There was 2 questions here saying injecting the whole service container should solve this. But question ... see below (note difference between try 2 & 3) ...

Try 1

public function __construct(SecurityContext $securityContext) {
    $this->securityContext = $securityContext);  
}

Curcular Reference. Okay ...

Try 2

public function __construct(ContainerInterface $container) {
    $this->securityContext = $container->get('security.context');  
}

Circular Reference (Why?, I am injecting the container like in try 3 except I got the security context only)

Try 3

public function __construct(ContainerInterface $container) {
    $this->container = $container;  
}

Works.

Mohammed H
  • 6,880
  • 16
  • 81
  • 127
Jiew Meng
  • 84,767
  • 185
  • 495
  • 805
  • post whole code example please. Circular Ref usually means that you're trying to inject a service that is already injected some other way into same class. (most popular problem is entity manager in doctrine listeners) – Inoryy Jan 03 '12 at 11:40

4 Answers4

24

This happens because your security context depends on this listener, probably via the entity manager being injected into a user provider. The best solution is to inject the container into the listener and access the security context lazily.

I typically don't like injecting the entire container into a service, but make an exception with Doctrine listeners because they are eagerly loaded and should therefore be as lazy as possible.

Kris Wallsmith
  • 8,945
  • 1
  • 37
  • 25
  • Hmm, makes some sense, but I don't get how "Try 2" should fail when 3 succeeds. Yes, its "lazy" but would an instance variable mess up the workings of another class? Hmm ... – Jiew Meng Jan 03 '12 at 14:41
  • The container keeps track of what services it is in the process of creating. If `get()` is called for one of these services it is already in the process of creating, a circular reference exception is thrown. That is why you are getting this exception when you call for the security context from inside the constructor, but not otherwise. When the constructor is called the container is already working on creating the security context. – Kris Wallsmith Jan 03 '12 at 17:29
  • 1
    Injecting the container is never «the best solution». I think the better approach would be to use «Lazy Services». – Slava Fomin II Mar 18 '15 at 08:47
  • Tried to make the dependencies on my `EventSubscriber` lazily loaded, but that still resulted into the same circular reference: https://symfony.com/doc/current/service_container/lazy_services.html Would there be another way now to not inject the container in the service? – Rvanlaak Nov 29 '16 at 13:23
8

As of Symfony 2.6 this issue should be fixed. A pull request has just been accepted into the master. Your problem is described in here. https://github.com/symfony/symfony/pull/11690

As of Symfony 2.6, you can inject the security.token_storage into your listener. This service will contain the token as used by the SecurityContext in <=2.5. In 3.0 this service will replace the SecurityContext::getToken() altogether. You can see a basic change list here: http://symfony.com/blog/new-in-symfony-2-6-security-component-improvements#deprecated-the-security-context-service

Example usage in 2.6:

Your configuration:

services:
    my.listener:
        class: EntityListener
        arguments:
            - "@security.token_storage"
        tags:
            - { name: doctrine.event_listener, event: prePersist }


Your Listener

use Doctrine\ORM\Event\LifecycleEventArgs;
use Symfony\Component\DependencyInjection\ContainerInterface;
use Symfony\Component\Security\Core\Authentication\Token\Storage\TokenStorageInterface;

class EntityListener
{
    private $token_storage;

    public function __construct(TokenStorageInterface $token_storage)
    {
        $this->token_storage = $token_storage;
    }

    public function prePersist(LifeCycleEventArgs $args)
    {
        $entity = $args->getEntity();
        $entity->setCreatedBy($this->token_storage->getToken()->getUsername());
    }
}
Anyone
  • 2,814
  • 1
  • 22
  • 27
1

The reason "2" fails and "3" does not is because in option 2 you are trying to access the security context immediately from the container when it is likely not populated yet.

As best I can tell, Symfony2 parses through the config and instantiates the service one after the other and then moves onto the handling the rest of the request.

This means you cannot necessarily access the various parts of the container because it may be loading them in a different order. So you have the memory pointer to the container, and store that, but then let the framework finish building the full container before you try to access parts of it. A notable exception to this is when you directly inject the service into another service, at which point the container is making sure it has that service loaded first.

You can see the effects of this by making two services. A and B. A is passed B, and B is passed A. Now you have a circular reference. If you instead passed the container into both A and B, you could not access A from B and B from A without a problem.

Wpigott
  • 814
  • 1
  • 7
  • 21
1

You should always try to avoid injecting container directly to your services.

I think the best possible solution to the «circular reference» problem as well as to possible performance issues, would be to use «Lazy Services» feature available starting from Symfony 2.3.

Just mark you dependency as lazy in your service container configuration and install ProxyManager Bridge (look for details in Lazy Services documentation above).

I hope that helps, cheers.

Slava Fomin II
  • 26,865
  • 29
  • 124
  • 202
  • This helped me in my case. But it is kind of weird that `ocramius/proxy-manager` library (needed for this feature be able to use) requires two zendframework libraries. Taking into account these dependencies I doubt that using lazy loading for not too big service graphs gives speed advantage.. – Arkemlar May 01 '17 at 11:56