Log::Any & Mojolicious - Adapter or Attach?

[ajmetz]

Any style/guidence advice on using Log::Any with Mojolicious? I've just got it working as a custom plugin that sets Log::Any::Adapter::MojoLog - it took me a while because I'm an idiot who likes his log messages to be in his Locale::Maketext lexicon perl modules - so I actually made my own custom adapter based off of Log::Any::Adapter::MojoLog that is identical except for running the log message through a translation first, based on a language handle that is passed in the same way the MojoLog is passed in when the adapter is set in the custom plugin.

With that up and working, I was browsing metacpan, and came across the following:
https://metacpan.org/pod/Mojo::Log::Role::AttachLogger
...which led me to discover...
https://metacpan.org/pod/Mojolicious::Plugin::Log::Any

So should I replace my custom plugin with that Grinnz authored plugin, and use the attach approach via a role, via the plugin?

What are the pros and cons of the two approaches?
I.e.
using a Log::Any::MojoLog adapter via a plugin,
versus
having Mojo::Log attach to Log::Any via a plugin?

Essentially what I want to do, is get into the habit of using the standard Log::Any API across both the mojolicious webapp stuff, and the business logic object classes of my app - which are potentially independent, but currently assume they will be called from my mojolicious webapp.

Of course, I may be able to answer my own question by looking at the source code of the role, and how it works.
So far I've seen the source of the plugin, and see it unsubscribes 'message' before attaching the logger.

[Grinnz]

The purpose of the attach approach is that logging can be done by Mojolicious via its normal logger, but those messages are sent to the other logging system (and, if you unsubscribe the original handler, turns off the standard logging mechanism). Since you're using Log::Any, you can also use that other logging system independently.

The MojoLog adapter is the reverse setup: Log::Any and its normal logging methods are the input, and the Mojo::Log object that you pass is the thing that does the actual logging. You could theoretically stack these and use Mojo::Log as both input and output, or vice versa, but it would be quite silly.

So in essence, I would suggest doing whatever makes the most sense for you between how you want to provide input and what mechanism you want to ultimately do the logging.

[XSven]

Maybe you are interested in the following issue too: preaction/Log-Any#114

This issue describes a deficit of the MojoLog adapter approach when it comes to log context information like the "request id". The MojoLog adapter cannot log structured/context data. I thought I could overcome this issue using $c->log (secondary logger that contains context) information instead of app->log. This by itself is ok but what is really wrong is to call Log::Any::Adapter->set() in the controllers instead of in the startup() method. This dynamic change of the adapter leads to the issue that I have mentioned above. I have not yet found any way to use Log::Any as my log producer and Mojo::Log as my log consumer to log context information in a safe way.