<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>
    <properties>
        <title>Extending Log4j 2</title>
        <author email="<EMAIL>"><NAME></author>
    </properties>

    <body>
      <section name="Extending Log4j">
        <p>
          Log4j 2 provides numerous ways that it can be manipulated and extended. This section includes an
          overview of the various ways that are directly supported by the Log4j 2 implementation.
        </p>
          <subsection name="LoggerContextFactory">
            <p>
              The LoggerContextFactory binds the Log4j API to its implementation. The Log4j LogManager
              locates a LoggerContextFactory by locating all instances of META-INF/log4j-provider.xml, a
              file that conforms to the java.util.Properties DTD, and then inspecting each to verify that it
              specifies a value for the "Log4jAPIVersion" property that conforms to the version required by the
              LogManager. If more than one valid implementation is located the value for "FactoryPriority" will
              be used to identify the factory with the highest priority.
              Finally, the value of the "LoggerContextFactory" property will be used to locate the
              LoggerContextFactory. In Log4j 2 this is provided by Log4jContextFactory.
            </p>
            <p>
              Applications may change the LoggerContextFactory that will be used by
              <ol>
                <li>Implementing a new LoggerContextFactory and creating a log4j-provider.xml to reference it making
                  sure that it has the highest priority.</li>
                <li>Create a new log4j-provider.xml and configure it with the desired LoggerContextFactory making
                  sure that it has the highest priority.</li>
                <li>Setting the system property "log4j2.loggerContextFactory" to the name of the LoggerContextFactory
                  class to use.</li>
                <li>Setting the property "log4j2.loggerContextFactory" in a properties file named
                  "log4j2.LogManager.properties" to the name of the LoggerContextFactory class to use. The properties
                  file must be on the classpath.</li>
              </ol>
            </p>
          </subsection>
          <subsection name="ContextSelector">
            <p>
              ContextSelectors are called by the Log4j LoggerContext factory. They perform the actual work of
              locating or creating a LoggerContext, which is the anchor for Loggers and their configuration.
              ContextSelectors are free to implement any mechanism they desire to manage LoggerContexts. The
              default Log4jContextFactory checks for the presence of a System Property named "Log4jContextSelector".
              If found, the property is expected to contain the name of the Class that implements the
              ContextSelector to be used.
            </p>
            <p>
              Log4j provides three ContextSelectors:
              <dl>
                <dt>BasicContextSelector</dt>
                <dd>Uses either a LoggerContext that has been stored in a ThreadLocal or a common LoggerContext.</dd>
                <dt>ClassLoaderContextSelector</dt>
                <dd>Associates LoggerContexts with the ClassLoader that created the caller of the getLogger call.</dd>
                <dt>JNDIContextSelector</dt>
                <dd>Locates the LoggerContext by querying JNDI.</dd>
              </dl>
            </p>
          </subsection>
          <subsection name="ConfigurationFactory">
            <p>
              Modifying the way in which logging can be configured is usually one of the areas with the most
              interest. The primary method for doing that is by implementing or extending a ConfigurationFactory.
              Log4j provides two ways of adding new ConfigurationFactories. The first is by defining the system
              property named "log4j.configurationFactory" to the name of the class that should be searched first
              for a configuration. The second method is by defining the ConfigurationFactory as a Plugin.
            </p>
            <p>
              All the ConfigurationFactories are then processed in order. Each factory is called on its
              getSupportedTypes method to determine the file extensions it supports. If a configuration file
              is located with one of the specified file extensions then control is passed to that
              ConfigurationFactory to load the configuration and create the Configuration object.
            </p>
            <p>
              Most Configuration extend the BaseConfiguration class. This class expects that the subclass will
              process the configuration file and create a hierarchy of Node objects. Each Node is fairly simple
              in that it consists of the name of the node, the name/value pairs associated with the node, The
              PluginType of the node and a List of all of its child Nodes. BaseConfiguration will then be
              passed the Node tree and instantiate the configuration objects from that.
            </p>
            <pre class="prettyprint linenums">
@Plugin(name = "XMLConfigurationFactory", category = "ConfigurationFactory")
@Order(5)
public class XMLConfigurationFactory extends ConfigurationFactory {

    /**
     * Valid file extensions for XML files.
     */<commit_msg>Add XSD and fix HTML.<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>Extending Log4j 2</title>
        <author email="rg<EMAIL>"><NAME></author>
    </properties>

    <body>
      <section name="Extending Log4j">
        <p>
          Log4j 2 provides numerous ways that it can be manipulated and extended. This section includes an
          overview of the various ways that are directly supported by the Log4j 2 implementation.
        </p>
          <subsection name="LoggerContextFactory">
            <p>
              The LoggerContextFactory binds the Log4j API to its implementation. The Log4j LogManager
              locates a LoggerContextFactory by locating all instances of META-INF/log4j-provider.xml, a
              file that conforms to the java.util.Properties DTD, and then inspecting each to verify that it
              specifies a value for the "Log4jAPIVersion" property that conforms to the version required by the
              LogManager. If more than one valid implementation is located the value for "FactoryPriority" will
              be used to identify the factory with the highest priority.
              Finally, the value of the "LoggerContextFactory" property will be used to locate the
              LoggerContextFactory. In Log4j 2 this is provided by Log4jContextFactory.
            </p>
            <p>
              Applications may change the LoggerContextFactory that will be used by
            </p>
            <ol>
              <li>Implementing a new LoggerContextFactory and creating a log4j-provider.xml to reference it making
                sure that it has the highest priority.
              </li>
              <li>Create a new log4j-provider.xml and configure it with the desired LoggerContextFactory making
                sure that it has the highest priority.
              </li>
              <li>Setting the system property "log4j2.loggerContextFactory" to the name of the LoggerContextFactory
                class to use.
              </li>
              <li>Setting the property "log4j2.loggerContextFactory" in a properties file named
                "log4j2.LogManager.properties" to the name of the LoggerContextFactory class to use. The properties
                file must be on the classpath.
              </li>
            </ol>
          </subsection>
          <subsection name="ContextSelector">
            <p>
              ContextSelectors are called by the Log4j LoggerContext factory. They perform the actual work of
              locating or creating a LoggerContext, which is the anchor for Loggers and their configuration.
              ContextSelectors are free to implement any mechanism they desire to manage LoggerContexts. The
              default Log4jContextFactory checks for the presence of a System Property named "Log4jContextSelector".
              If found, the property is expected to contain the name of the Class that implements the
              ContextSelector to be used.
            </p>
            <p>
              Log4j provides three ContextSelectors:
            </p>
            <dl>
              <dt>BasicContextSelector</dt>
              <dd>Uses either a LoggerContext that has been stored in a ThreadLocal or a common LoggerContext.</dd>
              <dt>ClassLoaderContextSelector</dt>
              <dd>Associates LoggerContexts with the ClassLoader that created the caller of the getLogger call.</dd>
              <dt>JNDIContextSelector</dt>
              <dd>Locates the LoggerContext by querying JNDI.</dd>
            </dl>
          </subsection>
          <subsection name="ConfigurationFactory">
            <p>
              Modifying the way in which logging can be configured is usually one of the areas with the most
              interest. The primary method for doing that is by implementing or extending a ConfigurationFactory.
              Log4j provides two ways of adding new ConfigurationFactories. The first is by defining the system
              property named "log4j.configurationFactory" to the name of the class that should be searched first
              for a configuration. The second method is by defining the ConfigurationFactory as a Plugin.
            </p>
            <p>
              All the ConfigurationFactories are then processed in order. Each factory is called on its
              getSupportedTypes method to determine the file extensions it supports. If a configuration file
              is located with one of the specified file extensions then control is passed to that
              ConfigurationFactory to load the configuration and create the Configuration object.
            </p>
            <p>
              Most Configuration extend the BaseConfiguration class. This class expects that the subclass will
              process the configuration file and create a hierarchy of Node objects. Each Node is fairly simple
              in that it consists of the name of the node, the name/value pairs associated with the node, The
              PluginType of the node and a List of all of its child Nodes. BaseConfiguration will then be
              passed the Node tree and instantiate the configuration objects from that.
            </p>
            <pre class="prettyprint linenums">
@Plugin(name = "XMLConfigurationFactory", category = "ConfigurationFactory")
@Order(5)
public class XMLConfigurationFactory extends ConfigurationFactory {

    /**
     * Valid file extensions for XML files.
     */
{'fraction_non_alphanumeric': 0.04974271012006861, 'fraction_numerical': 0.006315297052861375, 'mean_word_length': 2.2906618778860954, 'pattern_counts': {'":': 0, '<': 121, '<?xml version=': 2, '>': 121, 'https://': 0, 'lorem ipsum': 0, 'www.': 3, 'xml': 10}, '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': '6868872', 'n_tokens_mistral': 2881, 'n_tokens_neox': 2829, 'n_words': 1424}