Transform Support

[sandcastle]

I want to be able to pass in an object like HttpRequestMessage into log messages only store the information that is relevant - I also don't want to have extract the wanted information every time I write to the log as there would be a lot of duplicated code.

Also worth noting is that HttpRequestMessage as a property causes a StackOverflowException.

I'm thinking something like this (with a little more polish):

https://gist.github.com/sandcastle/5283376

Thoughts?

[sandcastle]

Guid's are an exmple of where some predefined maps might be required - currently a Guid is not being stored as I would expect.

[1/04/2013 1:35:58 PM +08:00] Information: "Request with API key {@key}."
key = Key { Id: Guid { }, Instance: "instance-a" }

[nblumhardt]

Thanks for the ideas, I like the direction the IPropertyMap points to - nice and easy to grasp. The current recursive all-or-nothing destructuring is a bit limited, I'd previously thought about building this somehow into the message template DSL, but your approach is much more DRY for the user.

Thanks for pointing out the Guid issue too, I'll treat that as a bug in the context of the current codebase (and a reminder to also set up stringification for Uri :)).

[nblumhardt]

Just occurred to me that in conjunction with implementing transform support, designating types as literals would also be useful (i.e. so that Guid and friends could be specified as literals by the user).

One gotcha also to think about -

When composing multiple independent modules/assemblies that share a logger, it may be problematic that what one module considers a literal, the other intends to be destructured. Making mapping/the destructuring strategy global, while message template parameters are provided in isolation by modules, could be a challenge.

One way around this might be to have one global "blessed strategy" that is baked into LoggerConfiguration, but to allow transformations/additional literal types to be configured on a context-by-context basis, i.e. for a local logger.

Trade-offs either way - funny how many subtleties there are.

Cheers!

[nblumhardt]

Made some progress on this. Refactored to centralise the message template processing, so that policies can be applied.

The main challenge now is to make it simple for a user to construct a property, given a value, while applying policies. E.g. LogEventProperty.For("Number", 42).

On the composability issue, if libraries want to control destructuring of parameters used in log messages, an attribute-based solution could cover 90% of cases. A default policy in Serilog could then respect the attributes.

[nblumhardt]

Transformation is implemented inline like this:

var log = new LoggerConfiguration()
    .TransformingValuesOf<HttpRequestMessage>(p => new 
    {
        Uri = p.RequestUri.AbsoluteUri,
        p.Method,
        p.Headers
    })
    ...

Underneath, and available also for use, is IDestructuringPolicy, which is a bit more flexible.

There's still a lot to do in this area, but to avoid losing focus on this item, I'll close this now and log new issues for remaining work.

Cheers!
Nick