feature #8580 Fix 3.3 DI changes with Symfony Flex structure (yceruto)

This PR was merged into the master branch.

Discussion
----------

Fix 3.3 DI changes with Symfony Flex structure

Commits
-------

9c5f7cc Fix 3.3 DI changes

Author: weaverryan

service_container/3.3-di-changes.rst

@@ -46,7 +46,7 @@ Symfony Standard Edition:
                 # if you need to do this, you can override this setting on individual services
                 public: false
 
-            # makes classes in src/AppBundle available to be used as services
+            # makes classes in src/ available to be used as services
             # this creates a service per class whose id is the fully-qualified class name
             App\:
                 resource: '../../src/*'
@@ -136,7 +136,7 @@ thanks to the following config:
         services:
             # ...
 
-            # makes classes in src/AppBundle available to be used as services
+            # makes classes in src/ available to be used as services
             # this creates a service per class whose id is the fully-qualified class name
             App\:
                 resource: '../../src/*'
@@ -180,7 +180,7 @@ This means that every class in ``src/`` is *available* to be used as a
 service. And thanks to the ``_defaults`` section at the top of the file, all of
 these services are **autowired** and **private** (i.e. ``public: false``).
 
-The service ids are equal to the class name (e.g. ``AppBundle\Service\InvoiceGenerator``).
+The service ids are equal to the class name (e.g. ``App\Service\InvoiceGenerator``).
 And that's another change you'll notice in Symfony 3.3: we recommend that you use
 the class name as your service id, unless you have :ref:`multiple services for the same class <services-explicitly-configure-wire-services>`.
 
@@ -289,8 +289,8 @@ argument with ``InvoiceGenerator``::
 
 That's it! Both services are :ref:`automatically registered <service-33-changes-automatic-registration>`
 and set to autowire. Without *any* configuration, the container knows to pass the
-auto-registered ``AppBundle\Service\InvoiceGenerator`` as the first argument. As
-you can see, the *type* of the class - ``AppBundle\Service\InvoiceGenerator`` - is
+auto-registered ``App\Service\InvoiceGenerator`` as the first argument. As
+you can see, the *type* of the class - ``App\Service\InvoiceGenerator`` - is
 what's most important, not the id. You request an *instance* of a specific type and
 the container automatically passes you the correct service.
 
@@ -379,7 +379,7 @@ The third big change is that, in a new Symfony 3.3 project, your controllers are
 But, you might not even notice this. First, your controllers *can* still extend
 the same base ``Controller`` class or a new :ref:`AbstractController <controller-abstract-versus-controller>`.
 This means you have access to all of the same shortcuts as before. Additionally,
-the ``@Route`` annotation and ``_controller`` syntax (e.g. ``AppBundle:Default:homepage``)
+the ``@Route`` annotation and ``_controller`` syntax (e.g. ``App:Default:homepage``)
 used in routing will automatically use your controller as a service (as long as its
 service id matches its class name, which it *does* in this case). See :doc:`/controller/service`
 for more details. You can even create :ref:`invokable controllers <controller-service-invoke>`
@@ -631,7 +631,7 @@ Start by updating the service ids to class names:
 
 But, this change will break our app! The old service ids (e.g. ``app.github_notifier``)
 no longer exist. The simplest way to fix this is to find all your old service ids
-and update them to the new class id: ``app.github_notifier`` to ``AppBundle\Service\GitHubNotifier``.
+and update them to the new class id: ``app.github_notifier`` to ``App\Service\GitHubNotifier``.
 
 In large projects, there's a better way: create legacy aliases that map the old id
 to the new id. Create a new ``legacy_aliases.yml`` file:
@@ -730,7 +730,7 @@ You're now ready to automatically register all services in ``src/``
         # ...
 
 That's it! Actually, you're already overriding and reconfiguring all the services
-you're using (``AppBundle\Service\GitHubNotifier`` and ``AppBundle\Service\MarkdownTransformer``).
+you're using (``App\Service\GitHubNotifier`` and ``App\Service\MarkdownTransformer``).
 But now, you won't need to manually register future services.
 
 Once again, there is one extra complication if you have multiple services of the
@@ -763,7 +763,7 @@ Step 5) Cleanup!
 To make sure your application didn't break, you did some extra work. Now it's time
 to clean things up! First, update your application to *not* use the old service id's (the
 ones in ``legacy_aliases.yml``). This means updating any service arguments (e.g.
-``@app.github_notifier`` to ``@AppBundle\Service\GitHubNotifier``) and updating your
+``@app.github_notifier`` to ``@App\Service\GitHubNotifier``) and updating your
 code to not fetch this service directly from the container. For example:
 
 .. code-block:: diff