Add autoconfigure for module loggers

The main technical challenge would be having different logger instances (channels) autowired per module.

For those new to autoconfigure, we have an instance in core as of #3221128: Enable service autoconfiguration for core event subscribers

Change record: https://www.drupal.org/node/3357408

Had a quick look at this, and it doesn't look like we know which module the services.yml is being loaded from. By the time we get to CoreServiceProvider we have a fully merged container definition.

This would make it hard to auto configure file.services.yml with a logger service id logger.channel.file for example.

One option is to loop through the service definitions and try to guess a prefix?

I was looking at \Drupal\Core\CoreServiceProvider::register() and adding something like:

$container->registerForAutoconfiguration(LoggerAwareInterface::class)
    ->addMethodCall('setLogger', [new Reference('logger.channel.default')]);

YamlFileLoader::parseDefinitions() appears to add a _provider tag to each service with the name of the module.

See also #3295542-10: Use logger channel services consistently, instead of the factory object where I suggested a similar idea.

Nice!

Having a look at this.

Tried an approach of first adding a logger_aware tag to any service with a class implementing \Psr\Log\LoggerAwareInterface by using +

$container->registerForAutoconfiguration(LoggerAwareInterface::class)
      ->addTag('logger_aware');

Then a \Drupal\Core\DependencyInjection\Compiler\LoggerAwarePass that looks for those tagged services.

Not finding my test service at the moment, so I thought I'd push up what I have to see if others have ideas?

Needed to add:

services:
  _defaults:
    autoconfigure: true

to logger_aware_test.services.yml.

Added a change record.

The CR doesn't mention the 'logger_aware' tag, but the code looks like it's still using it.

Overall I like this approach; previously I considered automatically creating lots of loggers but that just bloats the container - allowing this to be opt-in simply by implementing an interface is really clean.

I don't think there are any big issues but just to make sure we considered it: are there BC concerns here where services might have previously implemented LoggerAwareInterface and now we have added behaviour to that? Should we also check that the setLogger() method call isn't already present, just in case?

Should we also check that the setLogger() method call isn't already present, just in case?

Sorry, not sure I follow... We are only checking services that implement LoggerAwareInterface. The setLogger() method will always be there if they implement LoggerAwareInterface.

Updated CR

Ah I think I follow now.

Should we also check that the setLogger() method call isn't already present, just in case?

Sorry, not sure I follow... We are only checking services that implement LoggerAwareInterface. The setLogger() method will always be there if they implement LoggerAwareInterface.

We just need to check if the definition already has a setLogger method call defined.

I wonder if we should also detect LoggerInterface being used in service constructor arguments (as opposed to a setter method) and automatically create and inject a logger, if that argument is not yet wired - then we don't even need LoggerAwareInterface. Or should that be a followup?

Thinking again we should only do #23 if autowire: true is set which probably means we have to wait for #3295751: Autowire core services that do not require explicit configuration

This looks good to me as a self contained issue. I don't think we need to explicitly test that exception, nothing else to do here so this is RTBC.

One minor issue with PHPCS

Tests green ✅

Committed to 11.x and backported to 10.2.x

Published CR