One of the most common issues when using autowiring in Symfony applications is having two or more services implementing the same interface. The autowiring subsystem cannot guess which one to use in each case and you end up seeing this error message:
1 2
[Symfony\Component\DependencyInjection\Exception\RuntimeException]
Unable to autowire argument of type "..." for the service "...".
This problem is solved using the autowiring_types
option to define which is
the default implementation to use:
1 2 3 4 5 6 7
# app/config/services.yml
services:
annotations.reader:
class: Doctrine\Common\Annotations\AnnotationReader
autowiring-type: Doctrine\Common\Annotations\Reader
public: false
# ...
In Symfony 3.3 we decided to simplify this feature and autowiring-types are now deprecated. Instead, you must use simple service aliases:
1 2 3 4 5 6 7 8 9
# app/config/services.yml
services:
annotations.reader:
class: Doctrine\Common\Annotations\AnnotationReader
public: false
Doctrine\Common\Annotations\Reader:
alias: annotations.reader
public: false
It's recommended to create the new service aliases as private because you don't need them to be available in the compiled container.
Maybe you could add an example without the public false to show a usage with the short notation of alias ;)
@theofidry if the alias is meant to resolve autowiring conflicts, there is really no reason to make it public, which forces to keep it at runtime (and can then force to keep the service itself instead of inlining it, if the target is private too)
@Christophe maybe using
_defaults
would be nicer then?Typo in the second code snippet ?
autowiring-type
=>autowiring_types
@Simon is right :+1:
What if service implementation comes from a third-party bundle, e.g. someone creates their own entity manager? What can I do in this case without sending PR to it? For now, setting autowiring_types in CompilerPass works well for me.
@Victor just create an alias to this service provided by the bundle.