getsentry / getsentry/sentry-dotnet
[Log4Net] Support custom `SentryMessage` generation
- 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
Assessment
This issue has not been assessed yet.