to me, this new class should not be introduced either.

the removal of the debug loggers should either be implemented using a service configurator or we should make our debug processor itself able to behave like a no-op for environments where we don't want to collect those debug logs.

And the DebugLoggerInterface should be solved by injecting the DebugHandler in the collector instead of the main logger instance (which would be perfectly supported but is not wired this way in MonologBundle).

Let's first discuss about removing the@final inSeldaek/monolog#1827

Anyone up to do the PR implementing what@stof describes?

Sorry for being blunt but this looks like a mess to me. You'd get a Monolog class which you cannot even pass to something expecting a Logger instance (which you would right now do if you want to callreset() or smth on it.

Why not inject a DebugHandler in the Logger at runtime when in development for example?

Or worst case if you must extend Logger then go ahead and extend it, I just marked it final because people were extending it and doing crazy shit which then broke with new features. If you know what you are doing it is IMO safe to extend, and it's why it is just a@final and not a properfinal keyword. I don't want to prevent people, but I want to make it clear that it voids the warranty if you do extend.

Maybe it'd be worth layout out what exactly you are trying to solve here, because I am not 100% sure I am up to speed. I'm happy to try and help find a solution, but removing@final is a no go for me right now.