Auto-Registering All Services

Hey Mark!

Long time ;). Happy to hear from you. So, let's walk through. When you add this line to the config, Symfony literally starts opening each of your files in the resource path and looking for the classes it expects inside. When it opens the src/xxx/Bundle/AppBundle/Action/GeocodeXyzRelay.php file, it expects the class name of this class to be AppBundle\Action\GeocodeXyzRelay. Is that class name actually something else? Is it xxx\Bundle\AppBundle\Action\GeocodeXyzRelay? If so, change the AppBundle\:</code line in the config (the first line) to be xxx\Bundle\AppBundle:`. Symfony uses that first key to help "form" the class name that it expects in the files it finds. So, look at what it expects the class to be, and play with it a little.

If you can't figure it out, let me know - and tell me what the actual class name is in that file and we'll work it out :).

Cheers!

Hey Vincent,

I just downloaded the course code, went to finish/ directory, changed to "public: true" in services.yml, and ran "bin/console debug:container" without any errors. Probably cache problem? Could you try to clear the cache first and try again? Are you sure the problem in "public:true"? If you still have this issue - could you write the steps to reproduce it?

Cheers!

Hello, thanks for the time spent on my question.

I did copy the composer.json of finish/ directory so everything went up to normal. I guess there must have been some misconfiguration as I update the same directory with the next course code when i finish one. Bad practice leads to unexpected behavior.

Thank you very much!

Hey Vincent,

Glad you got it working! Yeah, sometimes we may do some required changes before starting a new course. That's might be a problem if you code along with us through the track and do all the changes in one project. But most of the time Ryan says what exactly was changed so you can look at start/ directory at least and find required changes you need to do to start the course.

Cheers!

Hey Zorpen,

Try to reload the page with Cmd + R / Ctrl + R, wait until the page is completely loaded, and play the video again - it should fix the problem. I also found this problem before by myself and these simple steps helped me. Not sure about where the problem is come from though, it's difficult to reproduce.

Cheers!

Thanks Victor.

Hey Ali,

Do you register any services which implement "Symfony\Component\HttpFoundation\Session\Attribute\AttributeBagInterface" interface in your application? I suppose it's coming from Symfony Core, and it means that there's nothing to do on your side. It will be fixed by Symfony in future releases, probably only in 4.0. So you can just ignore those deprecated messages from the core and focus on ones that related to *your* application, i.e. to your custom code.

Cheers!

Hiya Marc!

Apologies for my slow reply! So, great question. Let me answer in reverse :). This would not have a major impact on performance, though it would have a minor impact on performance. But first, more importantly, this should not be happening. So, we need to find out what all these new services are? First, make sure you have the public: false under _defaults. I'm guessing you do, but that is the first thing that could cause a problem (as all of the classes would be registered as public services and then not removed if they're unused). Also, make sure you've gone through the process of renaming all of your existing service id's to their class names (and using the legacy_aliases trick if needed).

If everything seems ok to you (i.e. you're not missing the public: false), if you could get a big list of the debug:container dump before and after, that might help. And how big is your project? Even if you forgot to set public: false, it looks like you're getting 450 new services... which would mean that your src directory has that many classes. Is your project huge, or not too big? It's interesting!

Cheers!

Hi Ryan,

Thanks for your reply. Public is on false. Only the controller are made public. I guess I have around 180 controllers, services and listeners in total. I ran debug:container and each file under controllers gets 3 entries in this list,e.g.

- abstract.instanceof.Master\AdminBundle\Controller\Master\User\UserEditController
- instanceof.Symfony\Bundle\FrameworkBundle\Controller\Controller.0.Master\AdminBundle\Controller\Master\User\UserEditController
- instanceof.Symfony\Bundle\FrameworkBundle\Controller\Controller.0.Master\AdminBundle\Controller\User\UserEdit\UserEditController

So this would amount to around 540 entries when debug:container is run.

When I run debug:container --types the list returns 385, about the same as the number of services before the migration.

One other question. Sometimes a controller needs to have a lot of services injected that are not all used for every request. Would it be better to make those services public and retrieve them from the container when the are necessary or would you recommend keeping them private and adding them all to the controller action or would you use a service locator?

Thanks.

Hey Marc!

Ah, you've found the critical part :). 180 controllers! Wow, that's amazing! :)

So, these abstract and instanceof stuff are "abstract" services (a super uncommon, low-level type of service) that are created by the container to help with the autoconfigure stuff. For controllers, if autoconfigure is true, then we automatically add the controller.service_arguments tag for you, if your controller extends either Controller or AbstractController. This tag is also applied manually in services.yml just in case. These abstract services are actually removed from the container - so they're not adding extra bloat. Why do they show up here? I actually found this same issue and checked into it briefly. If I remember correctly, it's either an easy fix (we just need to hide abstract services from this list) or a subtle ordering issue internally of when services are removed versus when this command is run. But in either case, these should not be in your final container. If you have any doubts, you can open the dumped container - var/cache/dev/appDevDebugProjectContainer.php - and search inside to verify they are not there.

Also, if you want, you can set autoconfigure: false under your controller import - and half... or all of these will go away. As I mentioned, these services help support the autoconfigure / instanceof functionality in Symfony 3.3... and it's not actually needed for controllers, because the tag is specified manually right in services.yml (we do both to be be doubly sure that you have the tag). Btw, that tag is responsible for your ability to autowire services as arguments to your controller.

Sometimes a controller needs to have a lot of services injected that are not all used for every request. Would it be better to make those services public and retrieve them from the container when the are necessary or would you recommend keeping them private and adding them all to the controller action or would you use a service locator?

GREAT question. As I can tell your already know, if you DI all those services through __construct, you're paying a penalty to instantiate some that you might not use. That's part of the reason why we created the argument autowiring for controllers: https://knpuniversity.com/screencast/symfony-3.3/controller-di-cleanup. If you use this method, not only is it more convenient... but services will only be instantiated that are needed for the one controller that was called. If you have some situation where even one controller method has a lot of conditional code so that you're injecting more than you need, I would (A) first refactor that code to a service and then (B) if it really is a performance problem, use a service locator inside that service. The new service locator stuff in 3.3 is really cool - though I don't know if we have service subscribers documented yet! https://github.com/symfony/symfony-docs/issues/7740

Cheers!

Thanks a lot. I'll refactor the code then.

Maybe one last question? When I change a class and reload a page, total load time is about 3 seconds (I am not worried about the first load..). Reloading a page after the first load is about 100 ms slower in the test environment with the new configurations settings then before.

I think this is probably caused by the extra work that has to be done checking if changes were made to any of the classes that are autoconfigured and autowired. What do you think?

Best wishes

And the final 2 questions for now.

1: I've noticed that even when a service is not public, it can sometimes be retrieved by referencing $container->get('AppBundle\ServiceName').

Is this supposed to happen. I would expect an error in this case...

2: When would you choose to make a service public and when private? In my project I have a couple of services that are used all over the place. In order to prevent replacing all these references I've opted to make these public and the rest private.

Cheers

Yo Marc Sanders!

Yep, there is some extra overhead in the dev (or test) environment with the new settings (even when the container is not being rebuilt on that request). It's exactly as you said - it has extra checks to see if files have changed or if constructor arguments have changed. Hopefully it's not too noticeable :). The container rebuild requests will also be a bit slower, but those should only happen when they need to. What I mean is, if you change some code in the middle of a class, it should not trigger a container rebuild. But if you change the constructor, it should re-trigger a rebuild. It's not 100% perfect (i.e. sometimes it will rebuild the container when you make a change that should not have caused a rebuild), but I hope we'll work out those edge cases over time.

Oh, also, this is part of the reason for the "exclude" tag. If you know you have some directories that are definitely not services, you can exclude those in services.yml. This will give you a minor (depending on how many you exclude) performance boost in the dev environment.

> I've noticed that even when a service is not public, it can sometimes be retrieved by referencing $container->get('AppBundle\ServiceName').

Ah, very good eye! Indeed, sometimes you can fetch a private service in this way - it relates to whether or not that service is used by multiple services (when it is, the container is built in such a way that it's accessible). But, this is not intended. Iirc, starting in Symfony 3.4 (could be 3.3, but I don't think it is), you will receive a deprecation warning when you try this, and in Symfony 4 it won't work (private services will never be accessible in this way).

Thanks for the great questions!

Thanks for the clear explanation.

Yo Argy,

Do you use "bin/console debug:container | wc -l" command when you have these 5 more services? Well, there's no performance issue, but probably you have a bit different content of config/services.yaml, can you make sure it matches ours? And the order of those declarations are the same like ours? Or, maybe, it was just some changes in the newest version you use that now includes all the registered controllers to the output, but I'm not sure 100%. But there's nothing to worry about.

Cheers!