| Subject: | Questions re wrapping / integrating with Log::Dispatchouli |
This is not so much a bug, but a confusion, a question, something that needs documenting.
For instance, I have https://metacpan.org/release/Log-Contextual-LogDispatchouli
And this is a tiny amount of glue so that Log::Dispatchouli will give useful stack traces with log_fatal, which calls Carp::croak
However, my question is how it should interact with other things.
My impression is that invoking the Log::Dispatchouli glue is something that shouldn't be required of everything that needs to log, and the things that require logging should simply use Log::Contextual, and not care about the implementation details.
However, because of the fact Log::Contextual shares state via $Log::Contextual::Router_Instance, and because I need to specify a non-standard router for Log::Dispatchouli integration to work as expected, I have 2 choices.
1. I should have my own package variable, and expect everything to `use Log::Contextual::LogDispatchouli`
2. Or I should somehow clobber $Log::Contextual::Route_Instance, so that everyone can `use Log::Contextual` and not worry about the backend.
#1 strikes me as the wrong approach, because telling everything in your software what the logging backend being used is , seems against the goals of LC.
So I'm asking for clarification on how I should integrate with that.
Also, related, there's a subtle interface problem that surrounds `log_fatal`.
Under log_fatal, Log::Dispatchouli croaks.
But no other logging backends do this.
So writing code that _expects_ log_fatal { } to die, results in undesirable continuation of code when the logging backend is not Log::Dispatchouli
And I'm not sure how to rectify this issue.