Closed optical closed 8 years ago
Hi Jared, thanks for the suggestion.
I'm not keen to head down the path of making this configurable right now, though I hope the code is a good basis to fork/modify for your kind of scenario.
The main reason I'm against it is that the number of possible modifications to the format is infinite, and so the customization points then either have to have arbitrary limitations, or become complex. I'd rather keep the codebase small and easy to understand, since in that state it's much easier to customize by forking anyway.
The secondary motivation is that I'd like to see how much the tooling can interoperate around the "compact JSON" format, and once it's customizable it will be more effort to add other tools that support the format (as these will then need to support the customizations as well). An experiment for now, anyway.
Cheers!
Sounds reasonable - closing this issue
This is a great little utility!
How would you feel about adding the ability to configure the mapping for field names in the JSON? We currently use Serilog with our own version of the compact formatter and have altered the field names to match the standard names we use internally for structured logging.
The simplest usecase would be a 1-1 mapping on the top-level of the object, which I think would cover the majority of the varying formats. However it might be nice to support reading in more complex / richer representations, such as the normal JSON format emitted by plain serilog (is there a solution for this already?).
Having had a look at the code, it looks like if we changed the
ClefFields
class up a bit we could achieve this, perhaps by introducing an interface consumers could implement for fetching out required fields from theJObject
, rather than just specifying the strings. This would allow parsing of more complicated formats, such as one where user properties are specified underneath the Properties field at the root of the event.I'd be happy to have a go at doing this if you think it sounds sane?