Log4j 2
  1. Log4j 2
  2. LOG4J2-362

Add a diagram to the site that explains when to use which jar

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0-beta8
    • Fix Version/s: 2.0-beta9
    • Component/s: Documentation
    • Labels:
      None

      Description

      The log4j-2.0 download archive contains a number of jar files.
      It is not always immediately clear to new users which jar files they should use. A diagram should help to clarify this.

      Examples of the kind of diagram intended:
      http://www.slf4j.org/legacy.html
      http://wiki.apache.org/tomcat/FAQ/Logging

      1. whichjar.png
        68 kB
        Remko Popma
      2. whichjar-slf4j.png
        26 kB
        Remko Popma
      3. whichjar-1.png
        67 kB
        Remko Popma
      4. whichjar-slf4j-1.png
        26 kB
        Remko Popma
      5. whichjar.xlsx
        14 kB
        Remko Popma
      6. whichjar-2.png
        67 kB
        Remko Popma

        Issue Links

          Activity

          Hide
          Remko Popma added a comment -

          attached whichjar.png initial version

          Show
          Remko Popma added a comment - attached whichjar.png initial version
          Hide
          Nick Williams added a comment -

          That diagram is extremely clear and helpful, Remko. Great job! Just a few minor corrections:

          1. API and Core JARs should be "log4j-api-2.0.jar" and "log4j-core-2.0.jar," respectively. Not "log4j-2.0-api.jar" and "log4j-2.0-core.jar."
          2. For the API and Implementation you call them "Log4j-2.0 API" and "Log4j-2.0 Implementation", but for the legacy API you call it "Log4j 1.0 API." I would omit the hyphen there. But I do agree with the placement of the number on the name, in this diagram.

          After reviewing it, two things occurred to me:

          • Should we have the Log4j Tag Library JAR on here somewhere? I'm not convinced, just wondering what others think.
          • It looks like maybe there's a need for a jul-to-log4j-2.0 module? Having to jump through the jul-to-slf4j then slf4j-api then log4j-slf4j-impl-2.0 artifacts seems like asking for performance issues.
          Show
          Nick Williams added a comment - That diagram is extremely clear and helpful, Remko. Great job! Just a few minor corrections: API and Core JARs should be "log4j-api-2.0.jar" and "log4j-core-2.0.jar," respectively. Not "log4j-2.0-api.jar" and "log4j-2.0-core.jar." For the API and Implementation you call them "Log4j-2.0 API" and "Log4j-2.0 Implementation", but for the legacy API you call it "Log4j 1.0 API." I would omit the hyphen there. But I do agree with the placement of the number on the name, in this diagram. After reviewing it, two things occurred to me: Should we have the Log4j Tag Library JAR on here somewhere? I'm not convinced, just wondering what others think. It looks like maybe there's a need for a jul-to-log4j-2.0 module? Having to jump through the jul-to-slf4j then slf4j-api then log4j-slf4j-impl-2.0 artifacts seems like asking for performance issues.
          Hide
          Remko Popma added a comment -

          attached whichjar-slf4j.png initial version

          Show
          Remko Popma added a comment - attached whichjar-slf4j.png initial version
          Hide
          Remko Popma added a comment -

          Ah, thanks Nick! I'll update in a few minutes.

          Show
          Remko Popma added a comment - Ah, thanks Nick! I'll update in a few minutes.
          Hide
          Remko Popma added a comment -

          attached whichjar-1.jar and whichjar-slf4j-1.jar that reflect Nick's suggestions.

          Show
          Remko Popma added a comment - attached whichjar-1.jar and whichjar-slf4j-1.jar that reflect Nick's suggestions.
          Hide
          Nick Williams added a comment -

          Looks better!

          I think JIRA allows you to mark attachments as obsolete (and it puts a line through them, but doesn't delete them for historical purposes). Can you do this for the original two attachments?

          Show
          Nick Williams added a comment - Looks better! I think JIRA allows you to mark attachments as obsolete (and it puts a line through them, but doesn't delete them for historical purposes). Can you do this for the original two attachments?
          Hide
          Remko Popma added a comment - - edited

          attached whichjar-2.jar (centers left-most arrow) and the source file (whichjar.xlsx) in Excel 2010 format.

          Show
          Remko Popma added a comment - - edited attached whichjar-2.jar (centers left-most arrow) and the source file (whichjar.xlsx) in Excel 2010 format.
          Hide
          Remko Popma added a comment -

          Nick, I only see "Delete" as possible action for the attachments. I'd prefer to keep the old ones to keep a record of the changes, so I don't really want to delete them...

          Show
          Remko Popma added a comment - Nick, I only see "Delete" as possible action for the attachments. I'd prefer to keep the old ones to keep a record of the changes, so I don't really want to delete them...
          Hide
          Nick Williams added a comment -

          There are actually several feature requests in JIRA's JIRA (is that like inception?) to support attachment obsolescing. However, I did find this helpful tidbit on a mailing list:

          Trick: upload the file with exactly the same name, then the latest one will be marked as "latest" (in mouse-over baloon), and earlier versions will be shown in gray.

          And this helpful tidbit on a JIRA, directly from a JIRA developer:

          At the moment JIRA does allow one to attach files with the same name to the issue and JIRA greys out the older files with the same name, such that visually one can tell which attachment is the newest. Does this work for you?

          Try that?

          Show
          Nick Williams added a comment - There are actually several feature requests in JIRA's JIRA (is that like inception?) to support attachment obsolescing. However, I did find this helpful tidbit on a mailing list: Trick: upload the file with exactly the same name, then the latest one will be marked as "latest" (in mouse-over baloon), and earlier versions will be shown in gray. And this helpful tidbit on a JIRA, directly from a JIRA developer: At the moment JIRA does allow one to attach files with the same name to the issue and JIRA greys out the older files with the same name, such that visually one can tell which attachment is the newest. Does this work for you? Try that?
          Hide
          Remko Popma added a comment -

          Added diagrams to the new FAQ page.
          Committed in revision 1519263.

          Show
          Remko Popma added a comment - Added diagrams to the new FAQ page. Committed in revision 1519263.

            People

            • Assignee:
              Remko Popma
              Reporter:
              Remko Popma
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development