-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[DI] [DX] Suggest what to do when container fails to autowire an inteface #22148
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[DI] [DX] Suggest what to do when container fails to autowire an inteface #22148
Conversation
530541b
to
7052cc3
Compare
(Sorry for the push-force. There were some typos. Now it should be OK.) |
Isn't the autowiring pass ran much later to avoid those issues? |
the order of service definition should not matter, as this code runs in a compiler pass, so after the whole file is loaded |
In Symfony 3.2.6 the order of service definition matters. I tested it. You can try it on the examples I posted in PR. |
@sustmi I'm using 3.2.6 and I don't have this issue. Could you try to reproduce it in a fork of the Standard Edition? |
Can you please try #22135? |
@theofidry: I am sorry, the example in the PR is probably a bad one. Try running php bin/console server:run. It will fail to compile the container. |
@nicolas-grekas: When I run the new example (https://github.com/sustmi/symfony-standard/tree/autowiring-order-dependent) on Symfony 3.2.6 the error message is:
while when I update Symfony to your PR (d7557cf) the message is following:
Both does not tell anything that would make developer think about the order of definitions. |
…rface Lets consider this example (two php files): --- class Service1 { public function __construct(MyInterface $my) ... } class Service2 implements MyInterface {} --- If you have the service Service2 defined before Service1 in your services.yml file then everything is OK. But if you have Service1 first and Service2 second you will get the following exception: --- [Symfony\Component\DependencyInjection\Exception\RuntimeException] Cannot autowire argument $my of method AppBundle\Model\Service1::__construct() for service "my_service1": No services were found matching the "AppBundle\Model\MyInterface" interface and it cannot be auto-registered. --- The same happens if you do not have Service2 in your services.yml and you want to autowire this: --- class Service3 { // Note that the interface is to be autowired before the service implementing the interface public function __construct(MyInterface $my1, Service2 $my2) } --- After this commit the exception message changes to: --- [Symfony\Component\DependencyInjection\Exception\RuntimeException] Cannot autowire argument $my1 of method AppBundle\Model\Service3::__construct() for service "my_service3": No services were found matching the "AppBundle\Model\MyInterface" interface and it cannot be auto-registered. Make sure that a service implementing "AppBundle\Model\MyInterface" interface is registered in the container before registering service "my_service3". --- Notice the last sentence. It suggests the developer what is the common case for this mistake and what can be the solution.
7052cc3
to
749d14e
Compare
Meanwhile I updated the PR for the current master. |
To clarify the issue the problem with wrong order happens when DIC has to auto-register a class and not when all services are registered explicitly in The working example (
The not working example (
|
I confirm it's a bug. Not a trivial one to fix I'd say. Can you open an issue please, then I think we can close this PR. |
@nicolas-grekas: I opened a new issue #22162 as you advised and now I am closing this PR. |
Lets consider this example files:
If you have the service
Service2
defined beforeService1
in yourservices.yml
file then everything is OK.But if you have
Service1
first andService2
second you will get the following exception:Another example: The same happens if you do not have
Service2
in yourservices.yml
and you want to autowire this:After this PR the exception message changes to:
Notice the last sentence. It suggests the developer what is the common case for this mistake and what can be the solution.
UPDATE: The first described example actually does not cause any problem. See https://github.com/sustmi/symfony-standard/tree/autowiring-order-dependent for another example that presents the problem.