New in Symfony 2.7: Dependency Injection Improvements

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\MysqlLock...
sqlite.lock:
    class: Drupal\Core\Lock\SqliteLock...

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

# app/config/services.yml
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.yml
services:
    manager:
        class:     AppBundle\Manager\UserManager
        arguments: [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.yml
services:
    manager:
        class: AppBundle\Manager\UserManager
        arguments:
          - true
        calls:
          - method: setLogger
            arguments:
              - "@logger"
          - method: setClass
            arguments:
              - User
        tags:
          - name: manager
            alias: 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: request
        synchronized: 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

namespace AppBundle\Mail;

use Symfony\Component\HttpFoundation\Request;

class Mailer
{
    protected $request;

    public function setRequest(Request $request = null)
    {
        $this->request = $request;
    }

    // ...
}

1
2
3
4
5
6

# app/config/services.yml
services:
    mailer:
        class: AppBundle\Mail\Mailer
        calls:
            - [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.