Add Logging engine Log::Any and add support for context logging

[mikkoi]

Log::Any has a new feature: Logging structed data. Essentially it means that you can add a hash after or in place of the logging message.
This can be really convenient if you simultaneously write the information into logs as JSON and pump the JSON into a logviewer where you can search or categorise by any JSON element.

This PR adds a logger engine for Log::Any and changes Dancer2::Core::Role::Logger to support the action.

[xsawyerx]

Is there a particular benefit to putting this in core instead of a plugin on CPAN?

[mikkoi]

Is there a particular benefit to putting this in core instead of a plugin on CPAN?

No.

I actually considered that: building the whole thing as a plugin. That would mean creating a new set of keywords and a lot of duplicate code. I am okay with that.

However, I also wanted to raise the point that Dancer2's logging has shortcomings. It is not possible as it is to do what I need. I think we should consider Log::Any's example.

A true overhaul is not possible, though, because that would mean incompatible changes to the API.

[xsawyerx]

However, I also wanted to raise the point that Dancer2's logging has shortcomings. It is not possible as it is to do what I need. I think we should consider Log::Any's example.

Good to raise this point. Is there anything you would suggest to improve specifically? Maybe this could lead to a core improvement, regardless of this being merged into core or not.

("Doing this in core is very difficult because of how core is" is a fair reason to suggest doing this in core, but it also raises the question of what we can do better in it.)

[cromedome]

You can accomplish this already with Log::Any.

In your app config:

logger: LogAny
engines:
  logger:
    LogAny:
      logger:
        - JSON
        - structure.log

And then in your Dancer2 app:

get '/' => sub {
    debug { foo => 'bar', baz => 'bah' };
    template 'index';
};

Am I missing something?

Recommend we close this. I could do a PR to add this to the cookbook. What do y'all think?

[racke]

Yes, makes sense to me.

[mikkoi]

You can accomplish this already with Log::Any.

This doesn't work for me. It does not support structured logging.
Example of how structured logging could work:

info 'Create user', { user => 'Mikko', request_id => 123, trx_active => 1, };

And then the output would be:

{"level":"info","category":"MyApp:Web","message":"Create user","user":"Mikko","request_id":123,"trx_active":1,"file":"/[..]/lib/MyApp/Web.pm","line":234}

Additionally, to emulate Log::Any we could have command "log_context" to create "base" context for all logging done within the scope:

{
    logging_context { request_id => 123, };
    info 'Create user', { user => 'Mikko', trx_active => 1, };
}

[cromedome]

You can accomplish this already with Log::Any.

This doesn't work for me. It does not support structured logging.

It does; if you build a new skeleton app, make sure to disable the console logger in environments/development.yml. I just generated a new app from scratch and tried it. Can you try again and see if this meets your needs?

That being said, I find logging_context() intriguing.

[mikkoi]

You can accomplish this already with Log::Any.

This doesn't work for me. It does not support structured logging.

It does; if you build a new skeleton app, make sure to disable the console logger in environments/development.yml. I just generated a new app from scratch and tried it. Can you try again and see if this meets your needs?

It does close but not quite. I get this:

{"category":"Dancer2::Logger::LogAny","level":"debug","message":"{'baz' => 'bah','foo' => 'bar'}","timestamp":"2026-01-31T22:37:48.531242Z"}

When I want:

{"category":"Dancer2::Logger::LogAny","level":"debug","message":"","baz":"bah","foo":"bar","timestamp":"2026-01-31T22:37:48.531242Z"}

The problem is the {'baz' => 'bah','foo' => 'bar'} which would need to be processed separately.

It also doesn't handle a message and structure:

`debug "Something happens here", { foo => 'bar', baz => 'bah' };`

That being said, I find logging_context() intriguing.

We can add all sorts of additional info there which a logviewer can index.

[cromedome]

I see two different things happening in this PR:

• Fixing some shortcomings in Dancer2's logging
• Adding Log::Any support to the Dancer2 core

Would you please submit this as two separate PRs? The core logging improvements I would 👍 in a hot minute. The other requires some discussion:

• There is already https://metacpan.org/pod/Dancer2::Logger::LogAny from @1nickt
• Have two different Log::Any providers could cause some confusion for users
• Other than being in core, what does your version offer that the plugin doesn't?

If we merge this, I'd need to see some more docs on how to configure this adapter with multiple Log::Any adapters.

I am always happy to see PRs from you @mikkoi :) Look forward to working through this with you.

[1nickt]

Some thoughts:

I am in favor of adding support for structured logging to the core.

However, I think it's not needed to duplicate my plugin.

And, I would want the support to provide more options than simple Log::Any structured logging, i.e. arbitrary data structures -- not just a hashref -- as supported e.g. by Log::Any::JSON (which also provides millisecond timestamp resolution). This would require making _serialize more complex., though.

[mikkoi]

Thanks, @cromedome

This is quite radical proposal, but how about if we changed Dancer2's own logging system to Log::Any?
With the caveat that we can maintain backwards compatibility, of course.

[cromedome]

This is quite radical proposal, but how about if we changed Dancer2's own logging system to Log::Any? With the caveat that we can maintain backwards compatibility, of course.

I don't have an immediate answer, and need to dwell on that for a bit. There's a lot to think over there, and I am not sure the gains are worth the effort. I think Log::Any is overkill for a lot of our users. Other core team members might have another view they'd like to share.

[cromedome]

@mikkoi in the interim, I'd love a new/updated PR with the non-Log::Any part of this.

[veryrusty]

changed Dancer2's own logging system to Log::Any

I use Log::Any extensively for $work projects; yet I'm not keen on using it for the default logger.

For our apps, we want consitent logging calls everywhere, which is why we chose Log::Any. That implies using $log->info("hey"); in scripts, business logic modules and within dancer routes rather than using the DSL keywords. (The existing Dancer2::Logger::LogAny handles core logs.)

[1nickt]

SLIGHTLY OT ...

For our apps, we want consitent logging calls everywhere, which is why we chose Log::Any. That implies using $log->info("hey"); in scripts, business logic modules and within dancer routes rather than using the DSL keywords. (The existing Dancer2::Logger::LogAny handles core logs.)

Hi @veryrusty
I'm just curious what you mean when you say that you have to use $log in Dancer routes rather than the logging keywords. The logging keywords certainly can be used to log with the LogAny logger.

[veryrusty]

what you mean when you say that you have to use $log in Dancer routes

I think I said we wanted consistency. Sure, the keywords work. But consistently using $log everywhere has its benefits; such as being able to easily grep your code to see where logs are generated, and I find I mentally grok $log quicker than the individual level keywords (but that may be because I've done it this way for so long!).