Add ability to configure the PsrLogMessageProcessor

[HypeMC]

Adds the ability to configure the PsrLogMessageProcessor using semantic configuration.

See Seldaek/monolog#940, Seldaek/monolog#1046, Seldaek/monolog#1487.

[Seldaek]

Thanks

[Jeroeny]

Hi, was it known that this was a Backwards breaking change ?

Given the following configuration in PHP:

// ./config/packages/monolog.php

use Symfony\Config\MonologConfig;

return static function (MonologConfig $config): void {

    $config->handler('console')
        ->type('console')
        ->processPsr3Messages(false)
        ->channels()
            ->elements(['!event', '!doctrine']);
};

Which the signature of processPsr3Messages being: public function processPsr3Messages($value): static.

Updated to 3.8:

$ .\bin\console                        
TypeError {#4198
  #message: "Symfony\Config\Monolog\HandlerConfig::processPsr3Messages(): Argument #1 ($value) must be of type array, bool given, called in .\config\packages\dev\monolog.php on line 19"
  #code: 0
  #file: ".\var\cache\dev\Symfony\Config\Monolog\HandlerConfig.php"
  #line: 229
  trace: {
    .\var\cache\dev\Symfony\Config\Monolog\HandlerConfig.php:229 {
      Symfony\Config\Monolog\HandlerConfig->processPsr3Messages(array $value = []): ProcessPsr3MessagesConfig
      ›
      › public function processPsr3Messages(array $value = []): \Symfony\Config\Monolog\HandlerConfig\ProcessPsr3MessagesConfig
      › {
    }

You can see the new method signature in the trace. I had to change the config to:

// ./config/packages/monolog.php

use Symfony\Config\MonologConfig;

return static function (MonologConfig $config): void {

    $console = $config->handler('console')
        ->type('console');
    $console->processPsr3Messages()
        ->enabled(false);
    $console->channels()
        ->elements(['!event', '!doctrine']);
};

[Seldaek]

Ah that's quite a surprising problem to me.. Because as I understand it this solves the BC aspect for yaml/xml/..

                    ->beforeNormalization()
                        ->ifTrue(static function ($v) { return !\is_array($v); })
                        ->then(static function ($v) { return ['enabled' => $v]; })
                    ->end()

I am not sure if there is anything we can do to get the generated config accept booleans too?

[Jeroeny]

@Seldaek I noticed that too, but in PHP configs it would never be not an array due to the typehint. And ->variableNode
is probably not usable either, because then you can't use the arrayNode specific addDefaultsIfNotSet and such..

[HypeMC]

I didn't take the new config builder into consideration back when I initially made this PR 😞
I guess the best way to go about this would be to add a new process_psr_3_messages_options & keep process_psr_3_messages as it was before.

[Seldaek]

I had a quick chat with @nicolas-grekas and he agrees this is a bug in the config generator if it does not allow people to migrate configs in a BC way.. So ideally the parameter type should be removed from https://github.com/symfony/symfony/blob/5.4/src/Symfony/Component/Config/Builder/ConfigBuilderGenerator.php#L132 and perhaps other places, if anyone has time to do a PR there.

I think it might be more sensible to only remove the parameter types if normalization is active on that node (which indicates some sort of BC/type juggling might be involved), but I am not sure if that's possible at all.

[HypeMC]

I can do the PR, will open it some time today.

[jderusse]

If I'm not wrong, this PR symfony/symfony#44166 should have handled that case

[HypeMC]

PR opened symfony/symfony#46328