<commit_before><?xml version="1.0"?>
<!--
    Licensed to the Apache Software Foundation (ASF) under one or more
    contributor license agreements.  See the NOTICE file distributed with
    this work for additional information regarding copyright ownership.
    The ASF licenses this file to You under the Apache License, Version 2.0
    (the "License"); you may not use this file except in compliance with
    the License.  You may obtain a copy of the License at

         http://www.apache.org/licenses/LICENSE-2.0

    Unless required by applicable law or agreed to in writing, software
    distributed under the License is distributed on an "AS IS" BASIS,
    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    See the License for the specific language governing permissions and
    limitations under the License.
-->

<document xmlns="http://maven.apache.org/XDOC/2.0"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/XDOC/2.0 http://maven.apache.org/xsd/xdoc-2.0.xsd">
  <properties>
    <title>Log4j 2 Architecture</title>
    <author email="<EMAIL>"><NAME></author>
  </properties>

  <body>
    <section name="Architecture">
      <subsection name="Main Components">
        <p>Log4j uses the classes shown in the diagram below.</p>
        <img src="../images/Log4jClasses.jpg" title="Log4j 2 Class Relationships"
             alt="Log4j 2 Class Relationships"/>
        <p>Applications using the Log4j 2 API will request a Logger with a specific name from the
          LogManager. The LogManager will locate the appropriate LoggerContext and then obtain the Logger from it.
          If the Logger must be created it will be associated with the LoggerConfig that contains either a) the
          same name as the Logger, b) the name of a parent package, or c) the root LoggerConfig. LoggerConfig
          objects are created from Logger declarations in the configuration. The LoggerConfig is associated with
          the Appenders that actually deliver the LogEvents.
        </p>
        <h4>Logger Hierarchy</h4>
        <p>The first and foremost advantage of any logging API over plain
          <code>System.out.println</code>
          resides in its ability to disable
          certain log statements while allowing others to print unhindered. This
          capability assumes that the logging space, that is, the space of all
          possible logging statements, is categorized according to some
          developer-chosen criteria.
        </p>
        <p>In Log4j 1.x the Logger Hierarchy was maintained through a relationship between Loggers.
          In Log4j 2 this relationship no longer exists. Instead, the hierarchy is maintained
          in the relationship between LoggerConfig objects.
        </p>

        <p>Loggers and LoggerConfigs are named entities. Logger names are case-sensitive and
          they follow the hierarchical naming rule:
        </p>

        <div class="well">
          <dl>
            <dt>Named Hierarchy</dt>
            <dd>
              A LoggerConfig is said to be an <em>ancestor</em> of another LoggerConfig if its name followed by a dot
              is a prefix of the <em>descendant</em> logger name. A LoggerConfig is said to be a <em>parent</em> of a
              <em>child</em> LoggerConfig if there are no ancestors between itself and the descendant LoggerConfig.
            </dd>
          </dl>
        </div>

        <p>For example, the LoggerConfig named
          <code>"com.foo"</code>
          is a parent
          of the LoggerConfig named<code>"com.foo.Bar"</code>. Similarly,
          <code>"java"</code>
          is a parent of
          <code>"java.util"</code>
          and an
          ancestor of <code>"java.util.Vector"</code>. This naming scheme
          should be familiar to most developers.
        </p>

        <p>The root LoggerConfig resides at the top of the LoggerConfig hierarchy. It
          is exceptional in that it always exists and it is part of every hierarchy. A Logger
          that is directly linked to the root LoggerConfig can be obtained as follows:
        </p>
          <pre class="prettyprint">Logger logger = LogManager.getLogger(LogManager.ROOT_LOGGER_NAME);</pre>
        <p>
          Alternatively, and more simply:
        </p><commit_msg>Fix typo in architecture.doc (#609)<commit_after><?xml version="1.0"?>
<!--
    Licensed to the Apache Software Foundation (ASF) under one or more
    contributor license agreements.  See the NOTICE file distributed with
    this work for additional information regarding copyright ownership.
    The ASF licenses this file to You under the Apache License, Version 2.0
    (the "License"); you may not use this file except in compliance with
    the License.  You may obtain a copy of the License at

         http://www.apache.org/licenses/LICENSE-2.0

    Unless required by applicable law or agreed to in writing, software
    distributed under the License is distributed on an "AS IS" BASIS,
    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    See the License for the specific language governing permissions and
    limitations under the License.
-->

<document xmlns="http://maven.apache.org/XDOC/2.0"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/XDOC/2.0 http://maven.apache.org/xsd/xdoc-2.0.xsd">
  <properties>
    <title>Log4j 2 Architecture</title>
    <author email="<EMAIL>"><NAME></author>
  </properties>

  <body>
    <section name="Architecture">
      <subsection name="Main Components">
        <p>Log4j uses the classes shown in the diagram below.</p>
        <img src="../images/Log4jClasses.jpg" title="Log4j 2 Class Relationships"
             alt="Log4j 2 Class Relationships"/>
        <p>Applications using the Log4j 2 API will request a Logger with a specific name from the
          LogManager. The LogManager will locate the appropriate LoggerContext and then obtain the Logger from it.
          If the Logger must be created it will be associated with the LoggerConfig that contains either a) the
          same name as the Logger, b) the name of a parent package, or c) the root LoggerConfig. LoggerConfig
          objects are created from Logger declarations in the configuration. The LoggerConfig is associated with
          the Appenders that actually deliver the LogEvents.
        </p>
        <h4>Logger Hierarchy</h4>
        <p>The first and foremost advantage of any logging API over plain
          <code>System.out.println</code>
          resides in its ability to disable
          certain log statements while allowing others to print unhindered. This
          capability assumes that the logging space, that is, the space of all
          possible logging statements, is categorized according to some
          developer-chosen criteria.
        </p>
        <p>In Log4j 1.x the Logger Hierarchy was maintained through a relationship between Loggers.
          In Log4j 2 this relationship no longer exists. Instead, the hierarchy is maintained
          in the relationship between LoggerConfig objects.
        </p>

        <p>Loggers and LoggerConfigs are named entities. Logger names are case-sensitive and
          they follow the hierarchical naming rule:
        </p>

        <div class="well">
          <dl>
            <dt>Named Hierarchy</dt>
            <dd>
              A LoggerConfig is said to be an <em>ancestor</em> of another LoggerConfig if its name followed by a dot
              is a prefix of the <em>descendant</em> logger name. A LoggerConfig is said to be a <em>parent</em> of a
              <em>child</em> LoggerConfig if there are no ancestors between itself and the descendant LoggerConfig.
            </dd>
          </dl>
        </div>

        <p>For example, the LoggerConfig named
          <code>"com.foo"</code>
          is a parent
          of the LoggerConfig named <code>"com.foo.Bar"</code>. Similarly,
          <code>"java"</code>
          is a parent of
          <code>"java.util"</code>
          and an
          ancestor of <code>"java.util.Vector"</code>. This naming scheme
          should be familiar to most developers.
        </p>

        <p>The root LoggerConfig resides at the top of the LoggerConfig hierarchy. It
          is exceptional in that it always exists and it is part of every hierarchy. A Logger
          that is directly linked to the root LoggerConfig can be obtained as follows:
        </p>
          <pre class="prettyprint">Logger logger = LogManager.getLogger(LogManager.ROOT_LOGGER_NAME);</pre>
        <p>
          Alternatively, and more simply:
        </p>
{'fraction_non_alphanumeric': 0.07584557567475231, 'fraction_numerical': 0.007857874957294158, 'mean_word_length': 2.517020424509411, 'pattern_counts': {'":': 0, '<': 129, '<?xml version=': 2, '>': 129, 'https://': 0, 'lorem ipsum': 0, 'www.': 4, 'xml': 6}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4723795', 'n_tokens_mistral': 2266, 'n_tokens_neox': 2185, 'n_words': 982}