Added the handler_class option to customize a handler while keeping i…

[charliefancelli]

…ts original type.

Q	A
Branch?	3.x
Bug fix?	no
New feature?	yes
Deprecations?	no
Issues	Fix #...
License	MIT

This pull request adds support for specifying a custom handler class for Monolog handlers via configuration. This allows users to define which PHP class should be used for a handler, increasing flexibility and extensibility in logging configuration. The main changes include schema and config updates, as well as logic to validate and use the custom handler class if provided.

Configuration and Schema Updates:

• Added a new handler_class attribute to the Monolog XML schema (monolog-1.0.xsd) to allow specifying a custom handler class in XML configuration.
• Added a new handler_class option to the handler configuration tree in Configuration.php, defaulting to null.

Handler Instantiation Logic:

• Updated the handler building logic in MonologExtension.php to use the specified handler_class if provided, including a runtime check that the class exists, otherwise falling back to the default handler class for the given type.

Sample

monolog:
    handlers:
        main:
            type: stream
            handler_class: App\Monolog\CustomStreamHandler
            path: '%kernel.logs_dir%/%kernel.environment%.log'

[GromNaN]

You can already specify a type: service, id: <service_id>. I think that's the way.

[charliefancelli]

Defining a service requires redefining all the handler options at the service level, whereas this approach allows you to keep the original handler options and handle your own logic directly within the handler.
This way, you can switch from a “native” handler to a “custom” one simply by adding the option.

[stof]

This also means that we cannot ever change our handling of known handler types in the future because any change in the structure of the definition becomes a potential BC breaks for custom classes. That's a maintenance nightmare.

Supporting custom handlers only through custom service definitions was an explicit choice to make it possible to keep the bundle evolving without having to release every bugfix as a major version due to the BC impact.

So a big -1 vote from me on this PR.

[charliefancelli]

I understand your concern, and indeed this feature requires good knowledge of the codebase and proper maintenance awareness.
When you choose to use it, you implicitly know that updating the bundle will require some attention.
In my view, the bundle should allow developers to use this feature knowingly, but not take responsibility for supporting it over time.

Moreover, I don’t really see how this differs from using a service decoration, which is a common pattern in Symfony.
Once you decorate a service, you already accept that any future update may introduce potential issues with the decorator.