////
    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

        https://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.
////
= Plugins
Ralph Goers <rgoers@apache.org>; Matt Sicker <mattsicker@apache.org>

Log4j 1.x allowed for extension by requiring class attributes on most of
the configuration declarations. In the case of some elements, notably
the PatternLayout, the only way to add new pattern converters was to
extend the PatternLayout class and add them via code. One goal of Log4j
2 is to make extending it extremely easy through the use of plugins.

In Log4j 2 a plugin is declared by adding a
link:../log4j-core/apidocs/org/apache/logging/log4j/core/config/plugins/Plugin.html[`@Plugin`]
annotation to the class declaration. During initialization the
link:../log4j-core/apidocs/org/apache/logging/log4j/core/config/Configuration.html[`Configuration`]
will invoke the
link:../log4j-core/apidocs/org/apache/logging/log4j/core/config/plugins/util/PluginManager.html[`PluginManager`]
to load the built-in Log4j plugins as well as any custom plugins. The
`PluginManager` locates plugins by looking in five places:

1.  Plugin collection classes on the classpath that are loaded by java.util.ServiceLoader.
These classes are generated automatically during the build (more details below).
2.  (OSGi only) Serialized plugin listing files in each active OSGi
bundle. A `BundleListener` is added on activation to continue checking
new bundles after `log4j-plugins` has started. Bundles must register their plugin collection
class as an OSGi service.
3.  A comma-separated list of packages specified by the
`log4j.plugin.packages` system property.
4.  Packages passed to the static `PluginManager.addPackages` method
(before Log4j configuration occurs).
5.  The link:./configuration.html#ConfigurationSyntax[packages] declared
in your log4j2 configuration file.
6. Serialized plugin listing files on the classpath. These files were generated by
the plugin annotation processor in Log4j 2 2.x. These are processed to allow
compatibility.

If multiple Plugins specify the same (case-insensitive) `name`, then the
load order above determines which one will be used. For example, to
override the `File` plugin which is provided by the built-in
`FileAppender` class, you would need to place your plugin in a JAR file
in the CLASSPATH ahead of`log4j-core.jar`. This is not recommended;
plugin name collisions will cause a warning to be emitted. Note that in
an OSGi environment, the order that bundles are scanned for plugins
generally follows the same order that bundles were installed into the
framework. See
http://www.osgi.org/javadoc/r5/core/org/osgi/framework/BundleContext.html#getBundles()[`getBundles()`]
and
http://www.osgi.org/javadoc/r5/core/org/osgi/framework/SynchronousBundleListener.html[`SynchronousBundleListener`].
In short, name collisions are even more unpredictable in an OSGi environment.
////
TODO: in future, plugins will be able to be annotated with @Order which can override priorities
////

Plugin collection classes are generated by an annotation processor contained
in the log4j-plugins artifact which will automatically scan your code for
Log4j 2 plugins and generate a Java source file that references all the
located plugins. It will also generate a
META-INF/services/org.apache.logging.log4j.plugins.processor.PluginService
file in compliance with java.util.ServiceLoader.
There is nothing extra that needs to be done to enable this;
the Java compiler will automatically pick up the annotation processor on
the class path unless you explicitly disable it.

If annotation processing is disabled plugins may still be registered by either
[loweralpha]
.. manually providing a class that extends `org.apache.logging.log4j.plugins.processor.PluginService`
and identifies all the plugins and also declaring a
`META-INF/services/org.apache.logging.log4j.plugins.processor.PluginService` file
that provides the fully qualified name of the implemented class or
.. adding another compiler pass to the build process that
only handles annotation processing using the Log4j 2 annotation
processor class,
`org.apache.logging.log4j.plugins.processor.PluginProcessor`.
To do this using Apache Maven, add the following execution to your
_maven-compiler-plugin_ (version 2.2 or higher) build plugin:

[source,xml]
----
<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-compiler-plugin</artifactId>
  <version>3.1</version>
  <executions>
    <execution>
      <id>log4j-plugin-processor</id>
      <goals>
        <goal>compile</goal>
      </goals>
      <phase>process-classes</phase>
      <configuration>
        <proc>only</proc>
        <annotationProcessors>
          <annotationProcessor>org.apache.logging.log4j.plugins.processor.PluginProcessor</annotationProcessor>
        </annotationProcessors>
      </configuration>
    </execution>
  </executions>
</plugin>
----

As the configuration is processed the appropriate plugins will be
automatically configured and initialized.

Log4j 2 utilizes a few different categories of plugins which are described
in the following sections.

[#Core]
== Core

Core plugins are those that are directly represented by an element in a
configuration file, such as an Appender, Layout, Logger or Filter.
Custom plugins that conform to the rules laid out in the next paragraph
may simply be referenced in the configuration, provided they are
appropriate configured to be loaded by the PluginManager.

Core plugins follow a few simple dependency injection rules for binding
`Configuration` parameters into a factory entry point. Each plugin must
declare a static method annotated with `@PluginFactory`.
This method can either list all options as method parameters, or it can return
a new `Builder<T>` instance where options are available as either single-argument
`setFoo` or `withFoo` methods or fields. There are a few different attribute types
available to denote `Configuration` data that are injected by the plugin
framework. These are available as annotations that can either be used on the
method parameters to return an instance of the plugin, or they can be used on the
returned builder class's methods or fields. Each annotation may include the
name that must be present in the configuration in order to match the
configuration item to its respective parameter. If no name is specified, then
the name used is as follows:

* When annotated on a parameter, this will use the parameter name.
* When annotated on a single argument method, if the method name is prefixed by
  `set` or `with`, this will use the remainder of the method name. Otherwise, the
  full method name is used.
* When annotated on a field, this will used the field name.

There are dozens of plugins in Log4j Core that can be
used as examples for more complex scenarios including hierarchical
builder classes (e.g., see `FileAppender`). See
link:extending.html#Plugin_Builders[Extending Log4j with Plugin
Builders] for more details.

=== Attribute Types

link:../log4j-plugins/apidocs/org/apache/logging/log4j/plugins/PluginAttribute.html[`PluginAttribute`]::
  The parameter must be convertible from a String using a
  link:#TypeConverters[TypeConverter]. Most built-in types are already
  supported, but custom `TypeConverter` plugins may also be provided for
  more type support. Note that `PluginBuilderAttribute` can be used in
  builder class fields as an easier way to provide default values.
link:../log4j-plugins/apidocs/org/apache/logging/log4j/plugins/PluginElement.html[`PluginElement`]::
  The parameter may represent a complex object that itself has
  parameters that can be configured. This also supports injecting an
  array of elements.
link:../log4j-core/apidocs/org/apache/logging/log4j/core/config/plugins/PluginConfiguration.html[`PluginConfiguration`]::
  The current `Configuration` object will be passed to the plugin as a
  parameter.
link:../log4j-plugins/apidocs/org/apache/logging/log4j/plugins/PluginNode.html[`PluginNode`]::
  The current `Node` being parsed will be passed to the plugin as a
  parameter.
link:../log4j-plugins/apidocs/org/apache/logging/log4j/plugins/PluginValue.html[`PluginValue`]::
  The value of the current `Node` or its attribute named `value`.

=== Constraint Validators

Plugin factory fields, methods, and parameters can be automatically validated at
runtime using constraint validators inspired by the
http://beanvalidation.org/[Bean Validation spec]. The following
annotations are bundled in Log4j, but custom
link:../log4j-plugins/apidocs/org/apache/logging/log4j/plugins/validation/ConstraintValidator.html[`ConstraintValidators`]
can be created as well.

link:../log4j-plugins/apidocs/org/apache/logging/log4j/plugins/validation/constraints/Required.html[`Required`]::
  This annotation validates that a value is non-empty. This covers a
  check for `null` as well as several other scenarios: empty
  `CharSequence` objects, empty arrays, empty `Collection` instances,
  and empty `Map` instances.
link:../log4j-plugins/apidocs/org/apache/logging/log4j/plugins/validation/constraints/ValidHost.html[`ValidHost`]::
  This annotation validates that a value corresponds to a valid
  hostname. This uses the same validation as
  http://docs.oracle.com/javase/8/docs/api/java/net/InetAddress.html#getByName-java.lang.String-[`InetAddress::getByName`].
link:../log4j-core/apidocs/org/apache/logging/log4j/core/config/plugins/validation/constraints/ValidPort.html[`ValidPort`]::
  This annotation validates that a value corresponds to a valid port
  number between 0 and 65535.

[#Converters]
== Converters

Converters are used by
link:../log4j-core/apidocs/org/apache/logging/log4j/core/layout/PatternLayout.html[`PatternLayout`]
to render the elements identified by the conversion pattern. Every
converter must specify its category as "Converter" on the `@Plugin`
annotation, have a static `newInstance` method that accepts an array of
`String` as its only parameter and returns an instance of the
Converter, and must have a `@ConverterKeys` annotation present that
contains the array of converter patterns that will cause the Converter
to be selected. Converters that are meant to handle `LogEvent` must
extend the
link:../log4j-core/apidocs/org/apache/logging/log4j/core/layout/LogEventPatternConverter.html[`LogEventPatternConverter`]
class and must implement a format method that accepts a `LogEvent` and a
`StringBuilder` as arguments. The Converter should append the result of
its operation to the `StringBuilder`.

A second type of Converter is the FileConverter - which must have
"FileConverter" specified in the category attribute of the `@Plugin`
annotation. While similar to a `LogEventPatternConverter`, instead of a
single format method these Converters will have two variations; one that
takes an `Object` and one that takes an array of `Object` instead of
the `LogEvent`. Both append to the provided `StringBuilder` in the same
fashion as a `LogEventPatternConverter`. These Converters are typically
used by the `RollingFileAppender` to construct the name of the file to
log to.

If multiple Converters specify the same `ConverterKeys`, then the load
order above determines which one will be used. For example, to override
the `%date` converter which is provided by the built-in
`DatePatternConverter` class, you would need to place your plugin in a
JAR file in the CLASSPATH ahead of`log4j-core.jar`. This is not
recommended; pattern ConverterKeys collisions will cause a warning to be
emitted. Try to use unique ConverterKeys for your custom pattern
converters.

[#KeyProviders]
== KeyProviders

Some components within Log4j may provide the ability to perform data
encryption. These components require a secret key to perform the
encryption. Applications may provide the key by creating a class that
implements the
link:../log4j-core/apidocs/org/apache/logging/log4j/core/util/SecretKeyProvider.html[`SecretKeyProvider`]
interface.

[#Lookups]
== Lookups

Lookups are perhaps the simplest plugins of all. They must declare their
type as "Lookup" on the plugin annotation and must implement the
link:../log4j-core/apidocs/org/apache/logging/log4j/core/lookup/StrLookup.html[`StrLookup`]
interface. They will have two methods; a `lookup` method that accepts a
`String` key and returns a `String` value and a second `lookup` method that
accepts both a `LogEvent` and a `String` key and returns a `String`. Lookups
may be referenced by specifying $\{name:key} where name is the name
specified in the Plugin annotation and key is the name of the item to
locate.

[#TypeConverters]
== TypeConverters

link:../log4j-plugins/apidocs/org/apache/logging/log4j/plugins/convert/TypeConverter.html[`TypeConverter`]s
are a sort of meta-plugin used for converting strings into other types
in a plugin factory method parameter. Other plugins can already be
injected via the `@PluginElement` annotation; now, any type supported by
the type conversion system can be used in a `@PluginAttribute`
parameter. Conversion of enum types are supported on demand and do not
require custom `TypeConverter` classes. A large number of built-in Java
classes are already supported; see
link:../log4j-plugins/apidocs/org/apache/logging/log4j/plugins/convert/TypeConverters.html['TypeConverters']
and
link:../log4j-core/apidocs/org/apache/logging/log4j/core/config/plugins/convert/CoreConverters.html[`CoreConverters`]
for a more exhaustive listing.

Unlike other plugins, the plugin name of a `TypeConverter` is purely
cosmetic. Appropriate type converters are looked up via the `Type`
interface rather than via `Class<?>` objects only. Do note that
`TypeConverter` plugins must have a default constructor.

[#DeveloperNotes]
== Developer Notes

If a plugin class implements
http://docs.oracle.com/javase/6/docs/api/java/util/Collection.html[`Collection`]
or http://docs.oracle.com/javase/6/docs/api/java/util/Map.html[`Map`],
then no factory method is used. Instead, the class is instantiated using
the default constructor, and all child configuration nodes are added to
the `Collection` or `Map`.