Closed radimvaculik closed 1 year ago
In this case best solution would probably be to throw an exception in case logger is not instance of Tracy\Logger
. You are using different ILogger
implementation that does not support sending emails.
Do you override the logger yourself? Or is it overriden by some logging extension? I think I already solved that issue in both orisai/nette-monolog and contributte/monolog by preserving original logger (in case Tracy bridge is enabled)
@mabar I use final class SentryDecoratedTracyLogger implements ILogger
and use $this->parentLogger = Debugger::getLogger();
to preserve Tracy logging.
Oh, my solution is currently broken too.
It overrides logger returned by Debugger::getLogger()
and disables autowiring for service tracy.logger
so my ILogger
implementation is autowired instead even if service tracy.logger
is created before Monolog has chance to wire into Tracy.
But. Order matters. If Monolog extension is loaded first, Tracy sets options to incorrect logger.
My case would be fixed by replacing Tracy\Debugger::getLogger()->mailer =
by $this->getService('tracy.logger')->mailer =
in generated DIC
@radimvaculik I fixed the issue in orisai/nette-monolog. You should be fine if you copy LazyTracyToPsrLogger changes to your SentryDecoratedTracyLogger https://github.com/orisai/nette-monolog/commit/6f39f961c583feb7061cbdb7435bfad16e6191cc#diff-34f516dc85e79726f910d1b0e989ea939cbf310611cf0507e69eee3b4a12a127R56-R110
I have this problem as well, using Contributte/Logging. Obviously this code Tracy\Debugger::getLogger()->mailer = ?;
should not rely on the property to maybe exist, rather there should be something like MailLogger interface having the setMailer function.
Adding @ to suppress the deprecation provides a quick fix.
I have the very same problem in a custom implementation of Tracy\ILogger
.
My current solution is to place a public $mailer
property on my implementation and ignore it's value.
And I 100% agree that Tracy\ILogger
does not support email and should not be treated as Tracy\Logger
(or anything) which supports email. If a mailer is to be set, you better make sure that you're dealing with Tracy\Logger
before you start accessing properties that cannot possibly ever exist on the interface (in fact, on any interface).
Adding magic methods to my implementation is a no go, Adding a setMailer() method to the interface (or an extended interface) seems viable even if it would be BC. I mean, unless the motto is "If it's broken and we cannot fix it without introducing a BC, we'd rather not fix it at all"....
Version: 2.9.5
Bug Description
With PHP 8.2, there is a deprecation error on dynamic properties.
Code
https://github.com/nette/tracy/blob/master/src/Bridges/Nette/TracyExtension.php#L120