Merge branch '2.3' into 2.4

Author: weaverryan

components/console/helpers/dialoghelper.rst

@@ -192,7 +192,7 @@ Instead, you can use the
 method, which makes sure that the user can only enter a valid string
 from a predefined list::
 
-    $dialog = $app->getHelperSet()->get('dialog');
+    $dialog = $this->getHelperSet()->get('dialog');
     $colors = array('red', 'blue', 'yellow');
 
     $color = $dialog->select(

components/dependency_injection/compilation.rst

@@ -7,7 +7,9 @@ Compiling the Container
 The service container can be compiled for various reasons. These reasons
 include checking for any potential issues such as circular references and
 making the container more efficient by resolving parameters and removing
-unused services.
+unused services. Also, certain features - like using
+:doc:`parent services </components/dependency_injection/parentservices>` -
+require the container to be compiled.
 
 It is compiled by running::
 

components/dependency_injection/configurators.rst

@@ -12,7 +12,7 @@ in a class. The service instance is passed to the callable, allowing the
 configurator to do whatever it needs to configure the service after its
 creation.
 
-A Service Configurator can be used, for example, when you a have a service that
+A Service Configurator can be used, for example, when you have a service that
 requires complex setup based on configuration settings coming from different
 sources/services. Using an external configurator, you can maintain the service
 implementation cleanly and keep it decoupled from the other objects that provide

components/event_dispatcher/introduction.rst

@@ -24,7 +24,7 @@ The Symfony2 EventDispatcher component implements the `Mediator`_ pattern in
 a simple and effective way to make all these things possible and to make your
 projects truly extensible.
 
-Take a simple example from the :doc:`/components/http_kernel/introduction`. Once a
+Take a simple example from :doc:`/components/http_kernel/introduction`. Once a
 ``Response`` object has been created, it may be useful to allow other elements
 in the system to modify it (e.g. add some cache headers) before it's actually
 used. To make this possible, the Symfony2 kernel throws an event -

components/http_foundation/sessions.rst

@@ -113,7 +113,7 @@ Session attributes
 * :method:`Symfony\\Component\\HttpFoundation\\Session\\Session::clear`:
   Clear all attributes.
 
-The attributes are stored internally in an "Bag", a PHP object that acts like
+The attributes are stored internally in a "Bag", a PHP object that acts like
 an array. A few methods exist for "Bag" management:
 
 * :method:`Symfony\\Component\\HttpFoundation\\Session\\Session::registerBag`:
@@ -137,7 +137,7 @@ Session Data Management
 ~~~~~~~~~~~~~~~~~~~~~~~
 
 PHP's session management requires the use of the ``$_SESSION`` super-global,
-however, this interferes somewhat with code testability and encapsulation in a
+however, this interferes somewhat with code testability and encapsulation in an
 OOP paradigm. To help overcome this, Symfony2 uses *session bags* linked to the
 session to encapsulate a specific dataset of attributes or flash messages.
 
@@ -236,7 +236,7 @@ Flash Messages
 
 The purpose of the :class:`Symfony\\Component\\HttpFoundation\\Session\\Flash\\FlashBagInterface`
 is to provide a way of setting and retrieving messages on a per session basis.
-The usual workflow for flash messages would be set in an request, and displayed
+The usual workflow would be to set flash messages in a request and to display them
 after a page redirect. For example, a user submits a form which hits an update
 controller, and after processing the controller redirects the page to either the
 updated page or an error page. Flash messages set in the previous page request

components/using_components.rst

@@ -10,7 +10,7 @@ one or more components, the easiest way to integrate everything is with `Compose
 Composer is smart enough to download the component(s) that you need and take
 care of autoloading so that you can begin using the libraries immediately.
 
-This article will take you through using the :doc:`/components/finder`, though
+This article will take you through using :doc:`/components/finder`, though
 this applies to using any component.
 
 Using the Finder Component

cookbook/logging/monolog.rst

@@ -79,6 +79,7 @@ allows you to log the messages in several ways easily.
     .. code-block:: xml
 
         <!-- app/config/config.xml -->
+        <?xml version="1.0" encoding="UTF-8" ?>
         <container xmlns="http://symfony.com/schema/dic/services"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xmlns:monolog="http://symfony.com/schema/dic/monolog"
@@ -179,6 +180,7 @@ easily. Your formatter must implement
     .. code-block:: xml
 
         <!-- app/config/config.xml -->
+        <?xml version="1.0" encoding="UTF-8" ?>
         <container xmlns="http://symfony.com/schema/dic/services"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xmlns:monolog="http://symfony.com/schema/dic/monolog"
@@ -293,6 +295,8 @@ using a processor.
 
     .. code-block:: xml
 
+        <!-- app/config/config.xml -->
+        <?xml version="1.0" encoding="UTF-8" ?>
         <container xmlns="http://symfony.com/schema/dic/services"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xmlns:monolog="http://symfony.com/schema/dic/monolog"
@@ -346,8 +350,101 @@ using a processor.
 
 .. note::
 
-    If you use several handlers, you can also register the processor at the
-    handler level instead of globally.
+    If you use several handlers, you can also register a processor at the
+    handler level or at the channel level instead of registering it globally
+    (see the following sections).
+
+Registering Processors per Handler
+----------------------------------
+
+You can register a processor per handler using the ``handler`` option of
+the ``monolog.processor`` tag:
+
+.. configuration-block::
+
+    .. code-block:: yaml
+
+        # app/config/config.yml
+        services:
+            monolog.processor.session_request:
+                class: Acme\MyBundle\SessionRequestProcessor
+                arguments:  ["@session"]
+                tags:
+                    - { name: monolog.processor, method: processRecord, handler: main }
+
+    .. code-block:: xml
+
+        <!-- app/config/config.xml -->
+        <?xml version="1.0" encoding="UTF-8" ?>
+        <container xmlns="http://symfony.com/schema/dic/services"
+            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+            xmlns:monolog="http://symfony.com/schema/dic/monolog"
+            xsi:schemaLocation="http://symfony.com/schema/dic/services
+                http://symfony.com/schema/dic/services/services-1.0.xsd
+                http://symfony.com/schema/dic/monolog
+                http://symfony.com/schema/dic/monolog/monolog-1.0.xsd"
+        >
+            <services>
+                <service id="monolog.processor.session_request" class="Acme\MyBundle\SessionRequestProcessor">
+                    <argument type="service" id="session" />
+                    <tag name="monolog.processor" method="processRecord" handler="main" />
+                </service>
+            </services>
+        </container>
+
+    .. code-block:: php
+
+        // app/config/config.php
+        $container
+            ->register('monolog.processor.session_request', 'Acme\MyBundle\SessionRequestProcessor')
+            ->addArgument(new Reference('session'))
+            ->addTag('monolog.processor', array('method' => 'processRecord', 'handler' => 'main'));
+
+Registering Processors per Channel
+----------------------------------
+
+You can register a processor per channel using the ``channel`` option of
+the ``monolog.processor`` tag:
+
+.. configuration-block::
+
+    .. code-block:: yaml
+
+        # app/config/config.yml
+        services:
+            monolog.processor.session_request:
+                class: Acme\MyBundle\SessionRequestProcessor
+                arguments:  ["@session"]
+                tags:
+                    - { name: monolog.processor, method: processRecord, channel: main }
+
+    .. code-block:: xml
+
+        <!-- app/config/config.xml -->
+        <?xml version="1.0" encoding="UTF-8" ?>
+        <container xmlns="http://symfony.com/schema/dic/services"
+            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+            xmlns:monolog="http://symfony.com/schema/dic/monolog"
+            xsi:schemaLocation="http://symfony.com/schema/dic/services
+                http://symfony.com/schema/dic/services/services-1.0.xsd
+                http://symfony.com/schema/dic/monolog
+                http://symfony.com/schema/dic/monolog/monolog-1.0.xsd"
+        >
+            <services>
+                <service id="monolog.processor.session_request" class="Acme\MyBundle\SessionRequestProcessor">
+                    <argument type="service" id="session" />
+                    <tag name="monolog.processor" method="processRecord" channel="main" />
+                </service>
+            </services>
+        </container>
+
+    .. code-block:: php
+
+        // app/config/config.php
+        $container
+            ->register('monolog.processor.session_request', 'Acme\MyBundle\SessionRequestProcessor')
+            ->addArgument(new Reference('session'))
+            ->addTag('monolog.processor', array('method' => 'processRecord', 'channel' => 'main'));
 
 .. _Monolog: https://github.com/Seldaek/monolog
 .. _LoggerInterface: https://github.com/php-fig/log/blob/master/Psr/Log/LoggerInterface.php