Added an auto_alias compiler pass¶

Contributed by
Daniel Wehner
in #12526.

This new feature emerged from the needs of the Drupal project. They define a series of related services like the following:

1
2
3
4
5
6

lock:class:Drupal\Core\Lock\Lock...mysql.lock:class:Drupal\Core\Lock\Lock...sqlite.lock:class:Drupal\Core\Lock\Lock...

When the site administrator sets the default_backend configuration option to mysql, the corresponding mysql.lock service should be automatically aliased to the generic lock service.

In Symfony 2.7 a new auto_alias compiler pass has been added to allow services to define aliases automatically based on the value of container parameters. You just need to tag your service with the new auto_alias tag and define the format of the alias (which can include any container parameter):

1
2
3
4
5

# app/config/services.ymllock:class:Drupal\Core\Lock\Lock...tags:-{name:auto_alias,format:"%default_backend%.lock"}

Improved service inlining when using the XML dumper¶

Contributed by
Christian Flothmann
in #14030.

In order to increase the application performance, the service container inlines services which are injected just once in the application if they are marked as private. When the cache gets built for an application's service container, the container itself is also dumped as an XML file (see appDevDebugProjectContainer.xml file in your application cache, for example).

However, this dump process failed in two cases: when you used a service configurator and when defining a private factory using the new factory syntax introduced in Symfony 2.6. These problems are now fixed in Symfony 2.7 and the XML dumper safely inlines any appropriate service.

Improved YAML service definition syntax¶

Contributed by
Martin Hasoň
in #13892.

YAML is one of the three configuration formats that Symfony applications can use to define their services. In Symfony 2.6 and previous versions, a complex service definition using YAML format looked as follows:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# app/config/services.ymlservices:manager:class:AppBundle\Manager\UserManagerarguments:[true]calls:-[setLogger,["@logger"]]-[setClass,["User"]]tags:-{name:twig.extension,alias:user}

In Symfony 2.7, the YAML configuration syntax has been improved to allow using a more verbose and expressive service definition (you can of course keep using the previous concise format if you prefer it):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

# app/config/services.ymlservices:manager:class:AppBundle\Manager\UserManagerarguments:-truecalls:-method:setLoggerarguments:-"@logger"-method:setClassarguments:-Usertags:-name:manageralias:user

Deprecated synchronized services¶

Contributed by
Fabien Potencier
in #13289.

In Symfony's service container, a service cannot depend on services from a narrower scope. For example, if you create a service and try to inject the request service, you will see a ScopeWideningInjectionException.

Symfony 2.3 introduced the concept of synchronized services as a way to solve this problem. That's why the request service is defined as synchronized:

1
2
3
4
5

services:request:scope:requestsynchronized:true# ...

Then in your service you can use setter injection to safely use this kind of synchronized services:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

namespaceAppBundle\Mail;useSymfony\Component\HttpFoundation\Request;classMailer{protected$request;publicfunctionsetRequest(Request$request=null){$this->request=$request;}// ...}

1
2
3
4
5
6

# app/config/services.ymlservices:mailer:class:AppBundle\Mail\Mailercalls:-[setRequest,["@?request"]]

However, the real problem is that the request is not a service but a value object. In Symfony 3.0, we will remove the request service from the container to fix the problem once and for all.

In addition, we have deprecated synchronized services in Symfony 2.7 because this feature is quite complex for something which is not really needed and was the wrong way to solve our problems. If your service needs the request service, use the request_stack service instead.