But one should be able to configure the decorated client before decorating it. I think not having this method encourages better instantiation steps. I get this can be helpful, but maybe here we'd prefer favoring better design?

But one should be able to configure the decorated client before decorating it

This doesn't work when injecting a scoped client from the framework configuration, as you are then stuck with the default logger and can't change it at runtime (E.G injecting a ConsoleLogger when running in CLI)

Thank you @pierredup.

I think that if you need an HttpClient with a different logger in some place, you should then configure a separate HttpClient exactly for this use case. Services are lazy-loaded, so it does not matter how many clients you have anyway.

Mutating services at Runtime is a bad practice — it leads to unpredictable behavior in services that reuse them. It's really sad that LoggerAwareInterface allows and encourages that. The best practice is to inject services via constructor, so that they cannot be replaced later.

Also decorators should not imply that inner services have some other interfaces and downcast them to figure that out. What if -1 inner client is not LoggerAware and -2 inner client is? This decorator will then fail to replace the logger.