enable byautoconfigure: true?

Belongs to monolog-bundle to me.

Looks good to me in the FrameworkBundle, as we now have the default logger from HttpKernel registered aslogger service if monolog (or any other one registering alogger service) isn't installed.

Shouldn't we check that method call ins't already called explicitly ?

@nicolas-grekas Actually I think adding method calls to autoconfigure instanceofs is forbiddenhttps://github.com/symfony/symfony/blob/master/src/Symfony/Component/DependencyInjection/Compiler/ResolveInstanceofConditionalsPass.php#L37, isn't it? Should we remove that restriction?

Calling a setter twice is not an issue to me so not really a pb.
And yes, we should remove the restriction in place.

@GaryPEGEOT Can you replace the removed test by a new one ensuring that method calls are handled?

@nicolas-grekas Actually autoconfigured calls seems not to be working out of the box (Or I'm missing something.):

/**     * Test that autoconfigured calls are handled gracefully.     */publicfunctiontestProcessForAutoconfiguredCalls()    {$container =newContainerBuilder();$container->registerForAutoconfiguration(LoggerAwareInterface::class)->addMethodCall('setLogger')->addTag('foo');$def =$container->register(\get_class($this->createMock(LoggerAwareInterface::class)));$this->assertFalse($def->hasTag('foo'),'Definition shouldn\'t have tags yet.');// Passes$this->assertFalse($def->hasMethodCall('setLogger'),'Definition shouldn\'t have method call yet.');// Passes        (newResolveInstanceofConditionalsPass())->process($container);$this->assertTrue($def->hasTag('foo'),'Definition should have "foo" tag.');// Passes$this->assertTrue($def->hasMethodCall('setLogger'),'Definition should have "setLogger" method call.');// Fail    }

And I see potential problems for calling set twice, if by example, method is overrided for any reason:

/**     * Sets a logger instance on the object.     *     * @param LoggerInterface $logger     * @param string          $channel Which channel to use     *     * @return void     */publicfunctionsetLogger(LoggerInterface$logger,string$channel =null)    {// TODO: Implement setLogger() method.    }

Here second parameter will be called with default param, so not necessary the expected behavior.

Compiler pass with tagged services seems to be the best option to me.

Actually autoconfigured calls seems not to be working out of the box (Or I'm missing something.):
And I see potential problems for calling set twice, if by example, method is overrided for any reason

I'm OK to agree with that. That makes me wonder we should make that work in fact. The current exception in place that prevents using setters was put in place exactly because we didn't bother fixing those topic at the time.

But I would definitely prefer merging a PR that fixes that, which would provide high generality to the feature, vs merging a hardcoded adhoc alternative. The compiler pass as is could really well be part of a third party bundle meanwhile if you really want it.

This makes sense. But this still requires the user to add the setLogger method. A better DX would be to add a new LoggerTrait with ‘@required’ above the setLogger method.

But this still requires the user to add the setLogger method

There is already aLoggerAwareTrait part of thepsr/log package.

I made a separate MR#24996 to allow auto-configured method calls

Closing in favor of#24996, thanks@GaryPEGEOT for taking over.