getsentry / getsentry/sentry-dotnet

[Log4Net] Support custom `SentryMessage` generation

Open
#1,437 3 comments 0 reactions 0 assignees View on GitHub
.NET Feature log4net
Dominant language
C#
Stars
770
Forks
248
Avg merge
3d 4h
Merged PRs (30d)
49

Description

Currently the `SentryAppender` always uses `LogEvent.RenderedMessage` property, when the message for an `SentryEvent` is created. This causes some problem for one application of mine ahead, which heavily uses formatted strings to generate log messages. The problem is, that a lot of events don't get recognized as the same, as they vary a lot. This could of couse be solved by using some custom fingerprinting, but it would be easier to utilize the existing `LogEvent.MessageObject` property, which _may_ contain the unformatted log message and its parameters, depending on the logger implementation.

# Possible solutions

As there are a lot of logger implementations in log4net there is no generic useful assumption, what type to expect from `MessageObject` so a flexible approach is needed. I have some ideas for a possible solution listed below.

## MessageFactory Callback

Add a new property `Func? MessageFactory { get; set; }` to the `SentryAppender` class. This function (if its not `null`) would then be called inside `Append()` before trying to read the message from `RenderedMessage` and the result would be used (again if its not `null`) instead of `RenderedMessage`.

The factory function may be moved into a new interface, to support setting the factory from the log4net xml configuration using a type name.

## Levering the `TypeConverter ` class

An other approach would be to call the `TypeDescriptor.GetConverter(...)` and see, wether there is a `TypeConverter`, thats supports converting to a `SentryMessage` instance

# Own opinion

I`d prefer the first proposal, as is rather easy to implement and would't require any reflection, which would be inevitable at least at one point using the `TypeConverter` approach. The added complexity needed for caching is also a drawback. On the other side that would bring an easy way to support more than type as `MessageObject`. But that could be also done in a custom implementation of my first idea.

I'm intrested, what you've got to say about it and i'd implement the feature, if there is a consence.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.