Closed ndrwrbgs closed 4 years ago
There are many ways to do it,. First one can modify the weaver and put this feature as a configuration switch. This way it would work for all adapters, log4net, serilog, etc. A less involved solution is to create your own adapter based on the source and modify the traceenter and traceleave implementations to skip parameters. Or if you just don't want to see the parameters in the log you might adjust the logging configuration (need to check if its possible with serilog). From performance perspective the first one is the best as it don't waste cycles on something that is not used. I'm currently updating Fody with some new features, I'll add this switch into the new version.
Thanks for the reply!
I’m actually writing a tracer based on this library but have the requirement that SOME methods have their arguments traced and some do not. I am looking at the source here and not seeing any easy way to pipe information from the weaver config file or the TraceOn down to my implementation. Would you have any ideas on that front?
Your answers on the various approaches for how to completely remove arguments were useful, thank you for that insight!
So, just to test if my understanding is correct, what you'd like to achieve is to pass down information from config and/or attributes to the logger adapter (TraceEnter and TraceLeave methods). Am I right?
Indeed, either pass down or have some static way to access it - any mechanism that allows me to read a config value at that location would enable the scenario like
[TraceOn(includeArguments: true)]
public void MyMethod(string args) {}
I think the TraceEnter and Leave methods' signature can be extended with an additional configuration argument which is injected at weaving time based on attribute or XML configuration. I'm thinking of a general argument (like a string) so that it can be used for different purposes by different implementations. Of course it would mean that we lose the type safety and extra info on the attribute. Like [TraceOn("IncludeArguments")]
. I'll see if I can find a way to keep the specificity of named arguments and still provide a general extensibility.
Anyway, the rewriter is now under a major update ('I'm almost finished with it), so I can probably add this feature as well.
Try beta3. It passes an array of Tuple<string, string> to both enter and leave methods. These extra config parameters can be used to modify the behaviour of the logger. The weaver fills these parameters based on
Sorry for latency, still alive but haven't gotten a chance to return to this yet :)
Finally cleaning up my tech debt I left in your project (this open issue) :-) https://github.com/ndrwrbgs/Tracer.OpenTracing.Fody/commit/b511a84896374a26e9ebceaa7f29f4f04b03f974
I wasn't able to (quickly) figure out how the config XML got passed, but in my scenario (we have secrets passed around in our code) configuring globally would be undesired anyway. There are some optimizations (like perhaps using ValueTuple, passing the values as object instead of turning them into strings) that we could make, but this issue is closed and if any of those show up in profiles later I'll send a PR
Say you were making the serilog tracer (which already exists), but wanted to NOT include the parameters on a method. How could you pass that configuration information from Fody's configuration, through
tracer
to the Serilog tracer itself?Are there any hooks to the Fody configuration or additional configuration mechanisms for the implementor?
Thanks!