NLog Forum › NLog-list

New feature coming to NLog v2 - wrapper layout renderers

2 messages

Jaroslaw Kowalski

New feature coming to NLog v2 - wrapper layout renderers

Reply Threaded

Some javascript/style in this post has been disabled (why?)

With the code cleanup that's happening in NLog v2 branch I realized that I could easily add a cool feature: Wrapper Layout Renderers which would help me restructure code to make it more maintainable and testable. I'd like to year your opinion about it.

What are Wrapper Layout Renderers (WLRs)?

Similar to wrapper targets, WLRs can modify output of other layout renderers, by doing textual transformations like:

* uppercase/lowercase conversion

* padding, trimming, alignment

* search/replace

* elision of excessive text

* encryption / masking of sensitive information

* cryptographic transformations (calculating MD5, SHA1 hashes, HMAC checksums)

* encoding: base64/uuencode, etc.

etc.

Note that many of those concerns are currently (in NLog v1) handled by LayoutRenderer itself. Being able to separate them into standalone, extensible classes is very convenient as you can add them separately and all existing layout renderers will be able to benefit from them.

So how are they used:

${uppercase:${level}} - will print log level in uppercase

${rot13:${message}} - will print ROT13 "encrypted" message

For config-file-level compatibility, you will still be able to use uppercase,lowercase,padding attributes that you know from NLog v1 directly on layout renderers etc.

To implement a wrapper, all you have to do is to create a class derived from WrapperLayoutRendererBase that overrides the Transform() method and apply the usual LayoutRenderer attribute.

Here's the ROT13 wrapper, which implements Caesar's cipher.

[LayoutRenderer("rot13")]
public sealed class Rot13LayoutRendererWrapper: WrapperLayoutRendererBase
{
    protected override string Transform(string text)
    {
        return DecodeRot13(text);
    }
}

You can of course define public properties as be able to set their values as with regular layout renderers.

I'm planning to add an additional concept called ambient properties which will help maintain NLog v1 compatibility while being very extensible. Ambient properties are properties that appear as if they were present on all layout renderers and when you actually use them, they add an implicit wrapper. This allows you to write: ${level:uppercase=true:padding=-10} instead of: ${padding:padding=-10:${uppercase:${level}}}

Whenever layout parser encounters an unknown property (such as "uppercase" which doesn't exist on LevelLayoutRenderer anymore) it will look for layout renderers which define [AmbientProperty("UpperCase")] and will instantiate them and use to wrap the original layout renderer:

[LayoutRenderer("uppercase")]
[AmbientProperty("UpperCase")]
public sealed class UpperCaseLayoutRendererWrapper : WrapperLayoutRendererBase
{
    private bool _upperCase = false;
    public bool UpperCase
    {
        get { return _upperCase; }
        set { _upperCase = value; }
    }
    protected override string Transform(string text)
    {
        return UpperCase ? text.ToUpperInvariant() : text;
    }
}

I have some prototype code on my box and I will check in for others to play with as soon as I get this to a stable state.

What do you think?

Jarek

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Nlog-list mailing list
Nlog-list@...
https://lists.sourceforge.net/lists/listinfo/nlog-list

Andrew Stone-2

Re: New feature coming to NLog v2 - wrapper layout renderers

Reply Threaded

Jarek,

If it's about making the code base more testable and maintainable sounds like a great idea.

You have done such a great job of 1.x! It's easy to use and has great performance.

Keep up the great work, NLog really is the best logging block for .NET.

Cheers,

Stonie.

2008/11/15 Jaroslaw Kowalski <jaak@...>

With the code cleanup that's happening in NLog v2 branch I realized that I could easily add a cool feature: Wrapper Layout Renderers which would help me restructure code to make it more maintainable and testable. I'd like to year your opinion about it.

What are Wrapper Layout Renderers (WLRs)?

Similar to wrapper targets, WLRs can modify output of other layout renderers, by doing textual transformations like:

* uppercase/lowercase conversion

* padding, trimming, alignment

* search/replace

* elision of excessive text

* encryption / masking of sensitive information

* cryptographic transformations (calculating MD5, SHA1 hashes, HMAC checksums)

* encoding: base64/uuencode, etc.

etc.

Note that many of those concerns are currently (in NLog v1) handled by LayoutRenderer itself. Being able to separate them into standalone, extensible classes is very convenient as you can add them separately and all existing layout renderers will be able to benefit from them.

So how are they used:

${uppercase:${level}} - will print log level in uppercase

${rot13:${message}} - will print ROT13 "encrypted" message

For config-file-level compatibility, you will still be able to use uppercase,lowercase,padding attributes that you know from NLog v1 directly on layout renderers etc.

To implement a wrapper, all you have to do is to create a class derived from WrapperLayoutRendererBase that overrides the Transform() method and apply the usual LayoutRenderer attribute.

Here's the ROT13 wrapper, which implements Caesar's cipher.

[
LayoutRenderer("rot13")]
public sealed class Rot13LayoutRendererWrapper: WrapperLayoutRendererBase
{
    protected override string Transform(string text)
    {
        return DecodeRot13(text);
    }
}
You can of course define public properties as be able to set their values as with regular layout renderers.

I'm planning to add an additional concept called ambient properties which will help maintain NLog v1 compatibility while being very extensible. Ambient properties are properties that appear as if they were present on all layout renderers and when you actually use them, they add an implicit wrapper. This allows you to write: ${level:uppercase=true:padding=-10} instead of: ${padding:padding=-10:${uppercase:${level}}}

Whenever layout parser encounters an unknown property (such as "uppercase" which doesn't exist on LevelLayoutRenderer anymore) it will look for layout renderers which define [AmbientProperty("UpperCase")] and will instantiate them and use to wrap the original layout renderer:

[
LayoutRenderer("uppercase")]
[AmbientProperty("UpperCase")]
public sealed class UpperCaseLayoutRendererWrapper : WrapperLayoutRendererBase
{
    private bool _upperCase = false;
    public bool UpperCase
    {
        get { return _upperCase; }
        set { _upperCase = value; }
    }
    protected override string Transform(string text)
    {
        return UpperCase ? text.ToUpperInvariant() : text;
    }
}
I have some prototype code on my box and I will check in for others to play with as soon as I get this to a stable state.

What do you think?

Jarek

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Nlog-list mailing list
Nlog-list@...
https://lists.sourceforge.net/lists/listinfo/nlog-list