[Templating] Circular reference detected for service "security.context"

[AlixBa]

I tried to inject the templating service and this is what I get.

<service id="myproject_notification.service.mail" class="%myproject_notification.service.mail.class%">
    <argument type="service" id="mailer" />
    <argument type="service" id="templating" />
</service>

If I comment, or remove, the templating service from the dependency, everything is working well. I saw old issues about that, but it seems I'm the only one at the moment experiencing this. Am I doing something wrong?

Composer.json

"symfony/symfony": "~2.4",
"twig/extensions": "~1.0",
"symfony/assetic-bundle": "~2.3",
"symfony/swiftmailer-bundle": "~2.3",
"symfony/monolog-bundle": "~2.4",
"sensio/distribution-bundle": "~2.3",
"sensio/framework-extra-bundle": "~3.0",
"sensio/generator-bundle": "~2.3",
"incenteev/composer-parameter-handler": "~2.0",

Composer.lock

"name": "symfony/symfony",
"version": "v2.5.0",
...
"name": "twig/twig",
"version": "v1.15.1",

Thanks,
Litz.

[stof]

the issue is that twig depends on the security context (one of the extension does actually), which itself depend on your grant_type service, which itself depend on your myproject_notification.service.mail service, which itself try to depend on twig (through the templating service). this indeed creates a circular dependency, making it impossible to instantiate the services (you cannot start the object graph anywhere).
the only way here is to refactor your code so that it does not create a cycle anymore (and I cannot help you based on only the service names)

[AlixBa]

Yep, I understand the circular reference problem, and what the source is.

The solution I'm using right now (thanks to someone on SO), is to get the templating system only when I want to render a twig file when I create a mail. But it makes me inject the whole container into my MailService.

I don't know if this schema can help, but this is my services and their dependencies for this case.

As said, the only solution would be to "cut" the link between my UserService and the grant type, right? Because I don't have any "access" for the red parts. They are from other bundles than mines.

[stof]

why does the UserService depend on the NotificationService here ?

[AlixBa]

Because on UserService::registerUser() I want to use the NotificationService to send a mail (NotificationService::sendRegistrationMailToUser()). NotificationService is just a facade for MailService and PushService (it allows me to inject only one service instead of to, if someday I want to send push notifications)

If I just link to MailService, the circular dependence will still be there, btw.

[stof]

My suggestion would be to have UserService dispatch an event when registering a user. Then, you can plug the listeners you want on this event (for instance a NotificationListener). Given that the event dispatcher loads listener lazily when dispatching, this would break the circular reference here (and it would also give you more flexibility if you want to perform another action on registration later, as you could simply register another listener without having to modify the UserService)

[AlixBa]

It sounds good. It makes sense to me that notifications are less related to business logic than the registerUser(setters, validation, persist). Does this solution affect the performances in a bad way?

[stof]

the overhead of dispatching the event rather than calling each method directly is probably negligeable compared to the business logic making DB calls. and for other places using the other methods of the UserService, it might even avoid instantiating the MailService entirely (assuming you don't have another place requiring to instantiate it of course).

[AlixBa]

At the moment, I'm just starting developping the NotificationService. But, indeed, it will be used in other bundles, in other services. If using the EventDispatcher is a good way to make a "clean&clear" solution, I can totally start with that.

Plus, you're right, the NotificationService is only used once in the UserService (send mail on register) even if this service only expose 3 functions, but I think some bigger services will use it for like one call in a total of 10 functions (and not the most called functions). So it can be good to avoid instanciate the NotificationService everytime.

[stof]

Can we close this issue ?

[AlixBa]

Of course! Thank you a lot for your help :)

[AlixBa]

Just to confirm, it works really well.

I made my NotificationService an EventSubscriber and I made it subscribe to the user_registration event. And instead of having a dependecy with NotificationService in UserService, I use EventDispatcher to be able to dispatch the user_registration event.

Obviously, I can now use the templating service inside my mailer without having any circular reference.