How to fix '...SomeController has no container set' on Controllers defined in Symfony 5 bundle?

Question

I have created a custom Symfony 5.3 bundle to share code between different projects. In src/controller/SomeController.php the bundle implements a controller class which extends from Symfony\Bundle\FrameworkBundle\Controller\AbstractController.

When accessing this controller via a route in my Symfony project I get the following error:

"XY\CommensBundle\Controller\SomeController" has no container set, did you forget to define it as a service subscriber?

AbstractController has a setContainer method which is used to inject the service container. On controllers implemented directly in my Symfony project this method is called automatically by autowire / autoconfigure.

However, regarding to the Symfony docs autowire / autoconfigure should not be used for bundle services. Instead, all services should be defined explicitly. So I added this to the bundles services.yaml:

# config/services.yaml
services:    
    xy_commons.controller.some_controller:
        class: XY\CommensBundle\Controller\SomeController
        public: false
        calls:     
            - [ setContainer, [ '@service_container' ]]

After adding the bundle to my Symfony project using Composer the console shows, that the controller is correctly added as a service. Everything seems fine.

php bin/console debug:container 'xy_commons.controller.some_controller'

Information for Service "xy_commons.controller.some_controller"
=============================================================

 ---------------- ------------------------------------------------------- 
  Option           Value                                                  
 ---------------- ------------------------------------------------------- 
  Service ID       xy_commons.controller.some_controller                    
  Class            XY\CommensBundle\Controller\SomeController 
  Tags             -                                                      
  Calls            setContainer                                           
  Public           no                                                     
  Synthetic        no                                                     
  Lazy             no                                                     
  Shared           yes                                                    
  Abstract         no                                                     
  Autowired        no                                                     
  Autoconfigured   no                                                     
 ---------------- -------------------------------------------------------

However, the error is still the same. So how to configure controllers / services in Bundles correctly?

EDIT:

SomeController is just a very basic subclass of AbstractController:

class SomeController extends AbstractController {
    public function some(): Response {
        return new Response("<html><body>OK</body></html>");
    }
}

Fully-qualified class name as Service ID

Usually I use FQCNs as Service ID. However, in this case I followed the advise from the Symfony docs (linked above) which explicitly say not to do so:

If the bundle defines services, they must be prefixed with the bundle alias instead of using fully qualified class names like you do in your project services. For example, AcmeBlogBundle services must be prefixed with acme_blog. The reason is that bundles shouldn’t rely on features such as service autowiring or autoconfiguration to not impose an overhead when compiling application services.

In addition, services not meant to be used by the application directly, should be defined as private.

This is way I used a snake name as ID and made the service private. The controller is not really used as service but only created automatically by Symfony when accessing / calling it via a route.

Controllers that rely on the calls or DI would need to be `public: true`, otherwise the controller as a [service will be removed at compilation time](https://symfony.com/doc/current/service_container.html#public-versus-private-services), as the services are not being injected by another service which triggers the calls or DI. Example: [symfony/framework-bundle 5.3 TemplateController and RedirectController config](https://github.com/symfony/framework-bundle/blob/5.3/Resources/config/routing.php#L167) — Will B., Aug 06 '21 at 21:10
You forgot an excerpt from the best-practice *"For public services, aliases should be created from the interface/class to the service id. For example, in MonologBundle, an alias is created from `Psr\Log\LoggerInterface` to logger so that the `LoggerInterface` type-hint can be used for autowiring."* Public service in this context would be sharable services, as the `logger` and `LoggerInterface` as of Symfony 3.4 [are not public services](https://github.com/symfony/monolog-bundle/blob/master/Resources/config/monolog.xml#L17). — Will B., Aug 07 '21 at 21:51

score 4 · Answer 1 · answered Aug 06 '21 at 17:01

I recently struggle with the same problem. This is the solution.

Suppose we have the Vendor/FooBundle bundle.

Controller with route annotations

<?php

namespace Vendor\FooBundle\Controller;

use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\Routing\Annotation\Route;

class EntryCategoryController extends AbstractController
{
    /**
     * @Route("/")
     */
    public function list()
    {
        $entryCategories = [];

        return $this->render('@VendorFoo/entry_category/list.html.twig', [
            'entryCategories' => $entryCategories
        ]);
    }
}

Register controller as service. The service id must be the controller fully-qualified class name, not a snake case string like vendor_foo.controller.entry_category. This is the key thing! Eventually you can create an alias for the controller service, but this is redundant.

# Resources/config/services.yaml

services:
    # The service id must be the controller fully-qualified class name.
    # If it a snake case string like `vendor_foo.controller.entry_category`,
    # then an alias must be created.
    # Vendor\FooBundle\Controller\EntryCategoryController:
    #     alias: '@vendor_foo.controller.entry_category'
    #     public: false

    Vendor\FooBundle\Controller\EntryCategoryController:
        # Setting class is redundant, but adds autocompletions for the IDE.
        class: Vendor\FooBundle\Controller\EntryCategoryController
        arguments:
        # Add this tag to inject services into controller actions.
        tags: ['controller.service_arguments'] 
        # Call the setContainer method to get access to the services via
        # $this->get() method.
        calls:
            - ['setContainer', ['@service_container']]

Routing file.

# Resources/config/routing.yaml

vendorfoo_entrycategories:
    resource: '@VendorFooBundle/Controller/EntryCategoryController.php'
    type: annotation
    prefix: /entry-categories

Import routing file in your app

# config/routes.yaml

vendor_foo:
    resource: '@VendorFooBundle/Resources/config/routing.yml'
    prefix: /foo

That's all.

Consider adding the container.service_subscriber tag and dropping the calls stuff. Injecting the full service container is something to be avoided. — Cerad, Aug 06 '21 at 17:40
@Cerad: Unfortunately adding the "container.service_subscriber" tag, not resolve this error **Controller" has no container set, did you forget to define it as a service subscriber?**. Only calling the "setContainer" method resolves this problem. — Artur Doruch, Aug 06 '21 at 18:14
Ah. Sorry about that. Normally bundle controllers are not supposed to extend AbstractController so I never noticed. It's actually autowire's job to inject the container. You could just set autowire: true and autoconfigure: true for controllers and it would all work without anything else needed. It's a tradeoff between using autowire which is discouraged in bundles and injecting the complete container which is always discouraged. — Cerad, Aug 06 '21 at 18:51
You save my life! As this states, the key part is "The service id must be the controller fully-qualified class name" — Gerardo, Mar 29 '22 at 07:59

score 2 · Answer 2 · answered Aug 06 '21 at 19:37

So @ArturDoruch has the correct main points. You should use the fully qualified class name as the service id though I suppose you could use snake case as long as you also used it in your routes file. But there is no particular reason not to use the class name.

Your controller service also needs to be public so the controller resolver can pull it from the DI container. If the service is not public then the resolver just tries to new the controller and will never call set container or inject any constructor args. That is why you get the error about no container set. By the way, a magical side effect of tagging the service with controller.service_arguments is that the service becomes public.

The thing is that using controllers in bundles is just not something you see much anymore mostly because it's a pain if application want to slightly tweak the way controller works.

So if you look in the best practices you see things like bundle controllers should not extend AbstractConroller and bundles should not use autowire. Good advice for most bundles but if you just want to get stuff working then it's easy to get bogged down.

I would suggest starting with the same services.yaml file that comes with the application. You need to tweak the paths slightly:

# Resources/config/services.yaml
services:

    _defaults:
        autowire: true
        autoconfigure: true

    MyBundle\:
        resource: '../../'
        exclude:
            - '../../Resources/'
            - '../../DependencyInjection/'
            - '../../Entity/'

# bin/console debug:container MyController
  Service ID       MyBundle\Controller\MyController  
  Class            MyBundle\Controller\MyController  
  Tags             controller.service_arguments      
                   container.service_subscriber      
  Calls            setContainer                      
  Public           yes                               
  Synthetic        no                                
  Lazy             no                                
  Shared           yes                               
  Abstract         no                                
  Autowired        yes                               
  Autoconfigured   yes

Now you can focus on just getting your bundle to work. Let autowire do the heavy lifting. Once the bundle has stabilized then maybe you can go back in and start to manually define your services as recommended in the best practices. Or maybe not.

Thanks Cerad for the details answer. The advise that best practice is not the best solution in all cases is a good point. Thus starting with autowire / autoconfigure is most likely a good idea. However, the docs say, that services **must** be prefixed with the bundle alias instead of using the FQCN. So are there really no side effects when not doing so? — Andrei Herford, Aug 07 '21 at 06:36
Can you point me to the relevant doc? From a big picture point of view, service id's need only be globally unique. They could be completely random and things would still work. Using the bundle's alias helps to ensure uniqueness and maintainability. But so does using FQCN. Something like MyBundle is not a good prefix. I should have used maybe Cerad\MyBundle but got lazy. — Cerad, Aug 07 '21 at 12:13
I think the OP is referring to the [reusable bundle services naming best-practices](https://symfony.com/doc/current/bundles/best_practices.html#services). In general though, there is nothing preventing a bundle from using the FQCN for services to allow for autowiring type-hints for use in a project, such as for the `monolog.logger` aliased as `logger` which is aliased as [`LoggerInterface`](https://github.com/symfony/monolog-bundle/blob/master/Resources/config/monolog.xml#L17) — Will B., Aug 07 '21 at 19:08
FQCN service definitions are applicable to Controllers as a service, as seen in the symfomy/framework-bundle definitions for [RedirectController](https://github.com/symfony/framework-bundle/blob/4.4/Resources/config/routing.xml#L119). I think the OP is misunderstanding the reasoning for using service names as opposed to FQCN. The point of the best-practice is to enforce explicitly defining services for the reusable bundle, reducing compilation overhead as a result, instead of implementing autowire in the reusable bundle. — Will B., Aug 07 '21 at 19:15
@WillB. Thanks for the link. The word 'must' is misleading in that it implies that you to do it one way or it won't work. Which is not the case. There is no technical reason that the id has to be snake case. I agree with your analysis. My 'answer' basically allows more rapid development of a bundle without getting bogged down in service definitions. Especially if the AbstractController class is to be used. — Cerad, Aug 07 '21 at 20:02

How to fix '...SomeController has no container set' on Controllers defined in Symfony 5 bundle?

EDIT:

2 Answers2

Linked