Add a local context to log methods

[baby-gnu]

Hello,

I appologies if I misunderstand the difference between context and structured logging, but the Log::Any::Adapter::Stdout does not render them equaly.

I'm starting to use Log::Any in some come and found that I'm repeated a lot the following code:

sub foo {
    local $log->context->{'foo} = 'bar';
    local $log->context->{'baz'} = 'qux';

    $log->info('Some message');
}

I think we could have a shortcut to pass local context:

sub foo {
    $log->info('Some message', context => { 'foo' => 'bar', 'baz' => 'qux' } );
}

Or is it strictly equivalent to:

sub foo {
    $log->info('Some message', { 'foo' => 'bar', 'baz' => 'qux' } );
}

When I'm using both context and structured data, they are not displayed in the same hash ref, for example:

sub foo {
    local $log->context->{'foo} = 'bar';
    $log->info('Some message', { 'baz' => 'qux' } );
}

Is outputed as:

Some message {baz => "qux"} {foo => "bar"}

I was expecting something like:

Some message {baz => "qux", foo => "bar"}

Regards.

[preaction]

I also think that it should be a single structure, so that the context is merged with the structure passed to the log message. Here's the discussion around that feature PR: https://github.com/preaction/Log-Any/pull/58#issuecomment-314564021 I would certainly be up to this change.

That thread also has some examples of using $log->context: https://github.com/preaction/Log-Any/pull/58#issuecomment-306889662 The context could also be turned into an object that returned scope guards, so you could do my $guard = $log->context->add( %hash ) and even my $guard = $log->context->replace( %hash ).

[mephinet]

Yeah, I think you're right, from the perspective of the log consumer it shouldn't make a difference whether some data is passed down via context or as part of the log function call. I'll come up with a pull request...

[preaction]

This has been fixed in v1.707 released to CPAN just now. Give it a bit for the mirrors to catch up. Thanks @mephinet for the patch, and @baby-gnu for the detailed bug report!