extending Log4PostSharp
4 posts • Page 1 of 1
extending Log4PostSharp
Log4PostSharp is great code, but why is the LogAttribute sealed? I would like the ability to extend Log4PostSharp so that I can log some information that doesn't come out of the box, as far as I can tell at least, using the parameters of Log4PostSharp (e.g., I'd like to log Environment.UserName & the current & calling assembly). What's the best way of doing this?
- codymay
- Posts: 8
- Joined: Mon Jun 09, 2008 8:53 pm
- First Name: Cody
- Last Name: May
Re: extending Log4PostSharp
Hi,
to log the additional information you need to add support for new placeholders in log messages. To make this you need to modify the Log4PostSharp source code (which requires you to know basics of CIL (MSIL) and low-level PostSharp components).
First you need to download the Log4PostSharp source code. In the "Log4PostSharp.Weaver" project there is a class "TemplateParser" which contains method named "ProcessPlaceholder". The method is called by the weaver for every encountered placeholder (i.e. text enclosed in "{" and "}") and is responsible for creating tokens for recognized placeholders (and throwing exception for unsupported ones). The tokens are simple objects that are used later to inject code that puts desired string on the evaluation stack. I think that in your case you need to create your own token class emitting CIL opcodes that, for instance, put value from the Environment.UserName onto the stack. Then you would need to add support for these tokens to the ProcessPlaceholder method. Please check the Log4PostSharp source code for further details (especially TemplateParser and token classes). I hope that this short description will help you finding the place where you can start from.
As a note: I plan to add general placeholder for logging value of any property. Unfortunately I'm not sure when I will have time for this (I hope that in 3-4 weeks).
to log the additional information you need to add support for new placeholders in log messages. To make this you need to modify the Log4PostSharp source code (which requires you to know basics of CIL (MSIL) and low-level PostSharp components).
First you need to download the Log4PostSharp source code. In the "Log4PostSharp.Weaver" project there is a class "TemplateParser" which contains method named "ProcessPlaceholder". The method is called by the weaver for every encountered placeholder (i.e. text enclosed in "{" and "}") and is responsible for creating tokens for recognized placeholders (and throwing exception for unsupported ones). The tokens are simple objects that are used later to inject code that puts desired string on the evaluation stack. I think that in your case you need to create your own token class emitting CIL opcodes that, for instance, put value from the Environment.UserName onto the stack. Then you would need to add support for these tokens to the ProcessPlaceholder method. Please check the Log4PostSharp source code for further details (especially TemplateParser and token classes). I hope that this short description will help you finding the place where you can start from.
As a note: I plan to add general placeholder for logging value of any property. Unfortunately I'm not sure when I will have time for this (I hope that in 3-4 weeks).
- herrmic
- Posts: 20
- Joined: Sat Jan 12, 2008 4:55 pm
- First Name: Michal
- Last Name: Dabrowski
Re: extending Log4PostSharp
Thanks for your helpful response. That's definitely too messy for my purposes; I don't know how difficult this would be, but making the Log4PostSharp LogAttribute have extensibility points that are somewhat similar to, e.g., PostSharp Laos's OnMethodBoundaryAspect would be quite helpful to users. Again, I don't know how difficult this would be to implement, however.
Thanks again for a good library nonetheless.
Thanks again for a good library nonetheless.
- codymay
- Posts: 8
- Joined: Mon Jun 09, 2008 8:53 pm
- First Name: Cody
- Last Name: May
Re: extending Log4PostSharp
Unfortunately, providing extensibility features similar to Laos would hurt performance significantly. Laos needs to do some relatively expensive preparations before it can call the method being injected, like collecting method arguments and creating EventArgs instances. Since Log4PostSharp is expected to be used with most of the methods in the application, such overhead would cumulate and result in noticeable application slowdown.
This is why Log4PostSharp uses low-level PostSharp framework instead of taking advantage of the Laos features. And this is also why I can't provide such flexibility as Laos does. Even with the current approach, logging parameters passed to a method may be problem if the method is called too often.
If you need more flexibility and do not care that much about the execution speed, you may create your own logging aspect that uses Laos.
This is why Log4PostSharp uses low-level PostSharp framework instead of taking advantage of the Laos features. And this is also why I can't provide such flexibility as Laos does. Even with the current approach, logging parameters passed to a method may be problem if the method is called too often.
If you need more flexibility and do not care that much about the execution speed, you may create your own logging aspect that uses Laos.
- herrmic
- Posts: 20
- Joined: Sat Jan 12, 2008 4:55 pm
- First Name: Michal
- Last Name: Dabrowski
4 posts • Page 1 of 1
