Log4net
  1. Log4net
  2. LOG4NET-10

Add %v pattern to output assembly version

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 1.2.9, 1.2.10
    • Fix Version/s: 1.2 Maintenance Release
    • Component/s: Core
    • Labels:
      None
    • Environment:
      From sourceforege - 775175 - Daniel Cazzulino (kzu) - dcazzulino

      Description

      n an environment where multiple versions of the same
      assembly is being used simultaneously by different
      applications, it's very useful to get the version of
      the assembly that is emiting the logging event.
      I'll add this right away. If you want the (rather
      trivial) code, I can post it.

      Daniel Cazzulino

      Well, the code is not trivial (to implement in a performant
      way), and our project is a little time-constrained.
      If I can, I'll try to make it, most probably in the
      LogManager.GetLogger method (the usage pattern indicates
      this will probably be a single static call per-class using
      logging)... I don't know.

      Daniel Cazzulino

      1. asm-patterns.patch
        12 kB
        Mark Mitchell
      2. asm-ver-desc-patterns.patch
        9 kB
        Mark Mitchell
      3. log4net.dll
        272 kB
        Mark Mitchell

        Activity

        Hide
        Nicko Cadell added a comment -

        The one LogManager.GetLogger per class pattern is only a suggestion, a rather string suggestion, but there are certainly a number of projects that don't follow this pattern.

        Show
        Nicko Cadell added a comment - The one LogManager.GetLogger per class pattern is only a suggestion, a rather string suggestion, but there are certainly a number of projects that don't follow this pattern.
        Hide
        Nicko Cadell added a comment -

        There seems to be low demand for this feature. Changing the priority to Minor.

        Show
        Nicko Cadell added a comment - There seems to be low demand for this feature. Changing the priority to Minor.
        Hide
        Mark Mitchell added a comment -

        Note: the patch was produced against revision 489241

        Here is potential solution for adding the assembly version to the output. I also included the assembly description attribute, as in our build process we stamp every assembly with the svn revision as part of its version field, and the svn url for its description field. Other assembly patterns useful to people could easily be added.

        %asm-ver is the pattern for version
        %asm-desc is the pattern for description

        The only reason I didn't use %v for the version attribute is because I also added the description attribute.

        Show
        Mark Mitchell added a comment - Note: the patch was produced against revision 489241 Here is potential solution for adding the assembly version to the output. I also included the assembly description attribute, as in our build process we stamp every assembly with the svn revision as part of its version field, and the svn url for its description field. Other assembly patterns useful to people could easily be added. %asm-ver is the pattern for version %asm-desc is the pattern for description The only reason I didn't use %v for the version attribute is because I also added the description attribute.
        Hide
        Ron Grabowski added a comment -

        We should probably expose all the Assembly attributes:

        %v

        {Description}

        %v

        {Title}

        %v

        {Version}

        %v

        {Trademark}

        ...

        Show
        Ron Grabowski added a comment - We should probably expose all the Assembly attributes: %v {Description} %v {Title} %v {Version} %v {Trademark} ...
        Hide
        Mark Mitchell added a comment -

        Should be applied to Revsion 675697

        Implements all attributes described in Ron's comment, except with the syntax

        %asm

        {Version}

        %asm

        {Title}

        %asm

        {Trademark}

        %asm

        {Description}
        Show
        Mark Mitchell added a comment - Should be applied to Revsion 675697 Implements all attributes described in Ron's comment, except with the syntax %asm {Version} %asm {Title} %asm {Trademark} %asm {Description}
        Hide
        Johannes added a comment - - edited

        Hi,

        thx for the enhancement on log4net. I really need this. Can someone explain me how I can install this patch-file, please?
        When will the version 1.2.11 be released?

        thx in advance.

        cheers

        Johannes

        Show
        Johannes added a comment - - edited Hi, thx for the enhancement on log4net. I really need this. Can someone explain me how I can install this patch-file, please? When will the version 1.2.11 be released? thx in advance. cheers Johannes
        Hide
        Mark Mitchell added a comment -

        The attached DLL file has the latest patch file I've uploaded applied.

        Normally to apply a patch file you just check out the SVN revision specified of the project, and use svn's apply patch mechanism. This will apply the modified/patched code. You can then build the project to receive the benefits of the patch.

        -Mark

        Show
        Mark Mitchell added a comment - The attached DLL file has the latest patch file I've uploaded applied. Normally to apply a patch file you just check out the SVN revision specified of the project, and use svn's apply patch mechanism. This will apply the modified/patched code. You can then build the project to receive the benefits of the patch. -Mark
        Hide
        Ron Grabowski added a comment -

        Mark, I looked at your patch and started writing some test cases and realized that you added support for storing assembly information about the repository. I think what Daniel and Nicko were talking about was wanting to add assembly information from where the log event was generated. For example:

        log.Info("Hello World");

        What version of the Company.BusinessLayer assembly did that come from?

        Company.BusinessLayer, Version=1.2.3.4, Culture=neutral, PublicKeyToken=null
        Company.BusinessLayer, Version=1.2.3.5, Culture=neutral, PublicKeyToken=null

        Daniel's suggestion about "a single static call per-class using logging" seems to hint that when the first logging event is generated from the class we capture information from the calling assembly. In other words, I think they're suggesting we add an Assembly property to one of the log classes (i.e. LogImpl) instead of (or in addition to) ILoggerRepository. If that's the case we'd need a way to differenciate the %asm pattern being assembly information about the repository vs. assembly information about the calling code.

        Does that make sense?

        Show
        Ron Grabowski added a comment - Mark, I looked at your patch and started writing some test cases and realized that you added support for storing assembly information about the repository. I think what Daniel and Nicko were talking about was wanting to add assembly information from where the log event was generated. For example: log.Info("Hello World"); What version of the Company.BusinessLayer assembly did that come from? Company.BusinessLayer, Version=1.2.3.4, Culture=neutral, PublicKeyToken=null Company.BusinessLayer, Version=1.2.3.5, Culture=neutral, PublicKeyToken=null Daniel's suggestion about "a single static call per-class using logging" seems to hint that when the first logging event is generated from the class we capture information from the calling assembly. In other words, I think they're suggesting we add an Assembly property to one of the log classes (i.e. LogImpl) instead of (or in addition to) ILoggerRepository. If that's the case we'd need a way to differenciate the %asm pattern being assembly information about the repository vs. assembly information about the calling code. Does that make sense?
        Hide
        Mark Mitchell added a comment -

        Ron,

        You are right – I added the assembly information about the logging repository. I think adding the assembly information about the calling code is the goal, but may not be simple to implement in an efficient way.

        The reason I implemented the assembly information about the repository is to support the following use case (which I think covers most of the uses of this type of feature):

        public class X

        { private static final ILog logger = LogManager.getLogger(typeof(X)); ... }

        Whenever the logger in the example above calls a log method, the assembly information I store in the logger repository is the same as the assembly for class X, and thus whenever logger outputs log messages, the proper assembly information from it is displayed. The information does not need to be dynamically found for every log call, but is properly setup in the LogManager.getLogger(typeof(X)) method, only the first time.

        The area where this will not work is if users do not use the pattern of one logger per class or use named loggers. However, I think enough people use the one logger per class mechanism that it might warrant having two approaches, especially since this way is probably going to be much faster than dynamically determining the calling assembly for every logging statement.

        Thoughts?

        -Mark

        Show
        Mark Mitchell added a comment - Ron, You are right – I added the assembly information about the logging repository. I think adding the assembly information about the calling code is the goal, but may not be simple to implement in an efficient way. The reason I implemented the assembly information about the repository is to support the following use case (which I think covers most of the uses of this type of feature): public class X { private static final ILog logger = LogManager.getLogger(typeof(X)); ... } Whenever the logger in the example above calls a log method, the assembly information I store in the logger repository is the same as the assembly for class X, and thus whenever logger outputs log messages, the proper assembly information from it is displayed. The information does not need to be dynamically found for every log call, but is properly setup in the LogManager.getLogger(typeof(X)) method, only the first time. The area where this will not work is if users do not use the pattern of one logger per class or use named loggers. However, I think enough people use the one logger per class mechanism that it might warrant having two approaches, especially since this way is probably going to be much faster than dynamically determining the calling assembly for every logging statement. Thoughts? -Mark

          People

          • Assignee:
            Ron Grabowski
            Reporter:
            Nicko Cadell
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:

              Development