Log4net
  1. Log4net
  2. LOG4NET-419

Adding Json layout to support simple integration with nxlog and similar destinations

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.2.13, 1.3.0
    • Fix Version/s: 1.3.0
    • Component/s: Core
    • Labels:

      Description

      Hi,

      I've created an extension which will effectively enable Json logging from log4net. It is implemented as a Layout so it can be used with pretty much any appender, especially the UDP appender :o). The aim is to enable fast local UDP drop off for logs in combination with nxlog. But I took care to allow code reuse and flexibility.

      https://sourceforge.net/projects/log4net-json/

      Please help me integrate this into log4net trunk.

      Thanks, Rob

        Activity

        Hide
        Dominik Psenner added a comment -

        Hi Robert,

        The idea is great. But in order to integrate your extension into log4net core there is still some work to be done.

        First of all your extension must respect backwards compatibility to old .NET frameworks (.NET 2.0 and above) or frameworks that do not reference System.Web.dll (Client profile, Compact Framework,..). This can be achieved with proper #ifdef's in the right spots. Json serialization will then simply unavailable on frameworks that do not have the System.Web.dll.

        Second please make sure to not conflict with either one of these:

        http://logging.apache.org/log4net/release/faq.html#thread-safe
        http://logging.apache.org/log4net/release/faq.html#features

        and make sure that your code complies to the contributing guidelines:

        http://logging.apache.org/log4net/release/faq.html#contributing-guidelines

        Once done that we can work on integrating your extension into log4net core. A patch that applies cleanly on the latest log4net trunk would undoubtedly speed up that process.

        Cheers

        Show
        Dominik Psenner added a comment - Hi Robert, The idea is great. But in order to integrate your extension into log4net core there is still some work to be done. First of all your extension must respect backwards compatibility to old .NET frameworks (.NET 2.0 and above) or frameworks that do not reference System.Web.dll (Client profile, Compact Framework,..). This can be achieved with proper #ifdef's in the right spots. Json serialization will then simply unavailable on frameworks that do not have the System.Web.dll. Second please make sure to not conflict with either one of these: http://logging.apache.org/log4net/release/faq.html#thread-safe http://logging.apache.org/log4net/release/faq.html#features and make sure that your code complies to the contributing guidelines: http://logging.apache.org/log4net/release/faq.html#contributing-guidelines Once done that we can work on integrating your extension into log4net core. A patch that applies cleanly on the latest log4net trunk would undoubtedly speed up that process. Cheers
        Hide
        Robert Sevcik added a comment -

        Hi Dominik, thanks a lot.

        Let's go step by step.

        1) Regarding .NET framework compatibility: I have given up on the System.Linq sugar all over, hence making it compile with .NET2. I have also introduced a simplistic JsonSerializer which will be used by default in place of the one provided with the .NET35 framework (JsonBuiltinSerializer). The compilation decisions are driven by the conditional FRAMEWORK_3_5_OR_ABOVE as in log4net trunk. Would that suffice to deliver backwards compatibility? Committed in revision 3: http://sourceforge.net/p/log4net-json/code/3/

        I have yet to adjust for compact framework and client profile.

        2) Formatting: Please review the code if it's worthy and point out any deficits. I'm using the default VS indentation style which makes tabs into 4 spaces. Does that need to change? What's the take on UTF8 BOM?

        3) Coding style: I've diverted from the standard property get/set encapsulating m_field where I found it fit and used default get/set without a field. Is it a policy or just an old habit to have a field for each property?

        4) Comments: I've followed the commenting style as best as I could.

        5) License: I've followed the licensing style as best as I could. It's the Apache license v2.

        6) Thread safety: I could use some advice here.

        7) Modularity and feature flexibility: I think it's delivered (since it's Layouts, PatternConverters and ObjectRenderrers) and beyond as the classes provide for future extensions and dependency injection.

        8) Speediness: I hope, need to do some benchmarking...

        9) Reliability and testing: I plan to introduce unit tests for the code's main features, but it's working well for my use cases.

        10) Patch: That will be simple as I'm not touching the original code. I'm actually compiling against a released log4net 1.2.13 dll. It should be a matter of dropping the files in place and including them in the project.

        Many thanks for your help and guidance.
        Kind regards, Rob

        Show
        Robert Sevcik added a comment - Hi Dominik, thanks a lot. Let's go step by step. 1) Regarding .NET framework compatibility: I have given up on the System.Linq sugar all over, hence making it compile with .NET2. I have also introduced a simplistic JsonSerializer which will be used by default in place of the one provided with the .NET35 framework (JsonBuiltinSerializer). The compilation decisions are driven by the conditional FRAMEWORK_3_5_OR_ABOVE as in log4net trunk. Would that suffice to deliver backwards compatibility? Committed in revision 3: http://sourceforge.net/p/log4net-json/code/3/ I have yet to adjust for compact framework and client profile. 2) Formatting: Please review the code if it's worthy and point out any deficits. I'm using the default VS indentation style which makes tabs into 4 spaces. Does that need to change? What's the take on UTF8 BOM? 3) Coding style: I've diverted from the standard property get/set encapsulating m_field where I found it fit and used default get/set without a field. Is it a policy or just an old habit to have a field for each property? 4) Comments: I've followed the commenting style as best as I could. 5) License: I've followed the licensing style as best as I could. It's the Apache license v2. 6) Thread safety: I could use some advice here. 7) Modularity and feature flexibility: I think it's delivered (since it's Layouts, PatternConverters and ObjectRenderrers) and beyond as the classes provide for future extensions and dependency injection. 8) Speediness: I hope, need to do some benchmarking... 9) Reliability and testing: I plan to introduce unit tests for the code's main features, but it's working well for my use cases. 10) Patch: That will be simple as I'm not touching the original code. I'm actually compiling against a released log4net 1.2.13 dll. It should be a matter of dropping the files in place and including them in the project. Many thanks for your help and guidance. Kind regards, Rob
        Hide
        Robert Sevcik added a comment -

        Hi, making progress.

        Ad 1) I am confident that reverse .NET compatibility is pretty much ready. This still needs to be tested, but it compiles fine back to 1.2.10 and .NET2 or .NET3.5 client profile. Initial tests are positive.

        Ad 2) Please comment on formatting.

        Ad 3) I'm ready to move to private m_fields and wrapping methods if needs be.

        Ad 4) same, resolved

        Ad 5) same, resolved

        Ad 6) I've been experimenting and testing but will still need a focused code review regarding thread safety.

        Ad 7) same, resolved

        Ad 8) That's where the progress was made. I created a benchmark and test UI for the JSON extension (or log4net in general). It shows in my tests that logging in JSON is actually faster than usual pattern layout when capturing the very same information and writing into very same appenders.

        Ad 9) Unit tests still pending, but the Test UI allows for a good trial.

        Ad 10) I'm still not touching the original code. I switched to developing against trunk, but compile as well against released versions. The trouble is that my project is growing with extra features: unique event stamps, keep-alive appender, besides the "just do JSON" code. I guess this would get split out into separate projects eventually, but not now as I already have 7 just to maintain the backwards compatibility. These features are easy to isolate.

        Show
        Robert Sevcik added a comment - Hi, making progress. Ad 1) I am confident that reverse .NET compatibility is pretty much ready. This still needs to be tested, but it compiles fine back to 1.2.10 and .NET2 or .NET3.5 client profile. Initial tests are positive. Ad 2) Please comment on formatting. Ad 3) I'm ready to move to private m_fields and wrapping methods if needs be. Ad 4) same, resolved Ad 5) same, resolved Ad 6) I've been experimenting and testing but will still need a focused code review regarding thread safety. Ad 7) same, resolved Ad 8) That's where the progress was made. I created a benchmark and test UI for the JSON extension (or log4net in general). It shows in my tests that logging in JSON is actually faster than usual pattern layout when capturing the very same information and writing into very same appenders. Ad 9) Unit tests still pending, but the Test UI allows for a good trial. Ad 10) I'm still not touching the original code. I switched to developing against trunk, but compile as well against released versions. The trouble is that my project is growing with extra features: unique event stamps, keep-alive appender, besides the "just do JSON" code. I guess this would get split out into separate projects eventually, but not now as I already have 7 just to maintain the backwards compatibility. These features are easy to isolate.
        Hide
        Robert Sevcik added a comment -

        Hi, I have stabilized the features and introduced tests. Please let me know what is required next to integrate to log4net trunk. I'm happy to support the inclusion. Thanks, Rob

        Show
        Robert Sevcik added a comment - Hi, I have stabilized the features and introduced tests. Please let me know what is required next to integrate to log4net trunk. I'm happy to support the inclusion. Thanks, Rob

          People

          • Assignee:
            Unassigned
            Reporter:
            Robert Sevcik
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:

              Time Tracking

              Estimated:
              Original Estimate - 24h
              24h
              Remaining:
              Remaining Estimate - 24h
              24h
              Logged:
              Time Spent - Not Specified
              Not Specified

                Development