added remaining part of introduction

Author: FreeAndNil

src/site/antora/modules/ROOT/pages/manual/appenders.adoc

@@ -103,4 +103,65 @@ The RollingFileAppender can be configured to log to multiple files based upon da
 |ForwardingAppender
 |Can be used to wrap another appender, for example to attach additional filters.
 
+|===
+
+[#appender-additivity]
+== Appender Additivity
+
+A logger can have multiple appenders.
+
+Each enabled logging request is passed to all appenders attached to that logger, and also to appenders higher in the logger hierarchy.
+This behavior is called *appender additivity* and is enabled by default.
+
+For example, if a console appender is attached to the root logger, all enabled logs will at least print to the console.
+If a file appender is added to logger `X`, logs from `X` and its children will go to both the file and the console.
+
+Additivity can be disabled by setting a logger’s `additivity` flag to `false`.
+This prevents logging events from being passed to ancestor appenders beyond that point.
+
+[NOTE]
+====
+If the `Animals` logger has `additivity = false`, then the `Animals.Carnivora` logger will only send its log messages to its own appenders and to `Animals`’ appenders—
+but not to any appenders higher up in the hierarchy, such as those on the root logger.
+====
+
+[cols="Logger Name,Added Appender,Additivity Flag,Output Targets,Comment"]
+|===
+|Logger Name |Added Appenders |Additivity Flag |Output Targets |Comment
+
+|root
+|ConsoleAppender
+|not applicable
+|ConsoleAppender
+|Default appender at the root.
+
+|Animals
+|FileAppender, RollingFileAppender
+|true
+|ConsoleAppender, FileAppender, RollingFileAppender
+|Appenders of "Animals" and root.
+
+|Animals.Carnivora
+|none
+|true
+|ConsoleAppender, FileAppender, RollingFileAppender
+|Inherited from "Animals" and root.
+
+|Animals.Carnivora.Felidae
+|SmtpAppender
+|true
+|ConsoleAppender, FileAppender, RollingFileAppender, SmtpAppender
+|Appenders in "Animals.Carnivora.Felidae", "Animals", and root.
+
+|Security
+|UdpAppender
+|false
+|UdpAppender
+|No appender accumulation because additivity is set to false.
+
+|Security.Access
+|none
+|true
+|UdpAppender
+|Only appenders of "Security" are used due to disabled additivity in "Security".
 |===

src/site/antora/modules/ROOT/pages/manual/filters.adoc

@@ -28,7 +28,7 @@ DENY:: The filter drops the log event.
 NEUTRAL:: log4net behaves as if the filter was not present.
 It is evaluated by the next filter in the filter chain.
 
-Any filter along the way can accept the event and stop processing, deny the event and stop processing, or allow the event on to the next filter. 
+Any filter along the way can accept the event and stop processing, deny the event and stop processing, or allow the event on to the next filter.
 If the event gets to the end of the filter chain without being denied it is implicitly accepted and will be logged.
 
 This filter will deny events that have a level that is lower than INFO or higher than FATAL. All events between INFO and FATAL will be logged.
@@ -40,7 +40,7 @@ This filter will deny events that have a level that is lower than INFO or higher
 </filter>
 ----
 
-If we want to only allow messages through that have a specific substring (e.g. 'database') then we need to specify the following filters: 
+If we want to only allow messages through that have a specific substring (e.g. 'database') then we need to specify the following filters:
 [source,xml]
 ----
 <filter type="log4net.Filter.StringMatchFilter">
@@ -55,7 +55,7 @@ If there is no next filter the event would be implicitly accepted and would be l
 But because we don't want the non matching events to be logged we need to use a log4net.Filter.DenyAllFilter that will just deny all events that reach it.
 This filter is only useful at the end of the filter chain.
 
-If we want to allow events that have either 'database' or 'ldap' in the message text we can use the following filters: 
+If we want to allow events that have either 'database' or 'ldap' in the message text we can use the following filters:
 [source,xml]
 ----
 <filter type="log4net.Filter.StringMatchFilter">
@@ -65,4 +65,32 @@ If we want to allow events that have either 'database' or 'ldap' in the message
   <stringToMatch value="ldap"/>
 </filter>
 <filter type="log4net.Filter.DenyAllFilter" />
-----
+----
+
+[#list-of-filters]
+== List of Filters
+
+The following filters are defined in the log4net package:
+
+[cols="Type,Description"]
+|===
+|Type |Description
+
+|log4net.Filter.DenyAllFilter
+|Drops all logging events unconditionally.
+
+|log4net.Filter.LevelMatchFilter
+|Allows only events with an exact level match.
+
+|log4net.Filter.LevelRangeFilter
+|Allows events within a specified range of levels.
+
+|log4net.Filter.LoggerMatchFilter
+|Matches events from loggers with names starting with a given string.
+
+|log4net.Filter.PropertyFilter
+|Matches events based on a specific property's value.
+
+|log4net.Filter.StringMatchFilter
+|Matches events containing a specific substring in the message.
+|===

src/site/antora/modules/ROOT/pages/manual/introduction.adoc

@@ -298,22 +298,41 @@ In fundamental contradiction to biological parenthood, where parents always prec
 
 In particular, a "parent" logger will find and link to its descendants even if it is instantiated after them.
 
-Configuration of the log4net environment is typically done at application initialization.
-The preferred way is by reading a configuration file.
-This approach will be discussed shortly.
+Logger configuration is usually done during application startup, typically via a configuration file.
 
-Log4net makes it easy to name loggers by software component.
-This can be accomplished by statically instantiating a logger in each class, with the logger name equal to the fully qualified name of the class.
+Loggers are often named after the class they’re used in, using the fully qualified class name.
+This makes log output easy to trace and aligns naturally with the application's design.
 
-This is a useful and straightforward method of defining loggers.
-As the log output bears the name of the generating logger, this naming strategy makes it easy to identify the origin of a log message.
+While other naming strategies are possible, this approach is simple, effective, and widely adopted.
 
-However, this is only one possible, albeit common, strategy for naming loggers.
-Log4net does not restrict the possible set of loggers.
-The developer is free to name the loggers as desired.
+[#appenders]
+== Appenders
 
-Nevertheless, naming loggers after the class where they are located seems to be the best strategy known so far.
-It is simple and obvious to the developers where each log message came from.
+See xref:./appenders.adoc[]
 
-Most importantly, it leverages the design of the application to produce the design of the logger hierarchy.
-Hopefully, some thought has gone into the design of the application.
+[#filters]
+== Filters
+
+See xref:./filters.adoc[]
+
+[#layouts]
+== Layouts
+
+See xref:./layouts.adoc[]
+
+[#renderers]
+== Object Renderers
+
+log4net can render the content of log messages using custom logic defined by the user.
+
+For example, if you often log `Orange` objects, you can register an `OrangeRenderer` to format them consistently in logs.
+
+Renderers follow the class hierarchy.
+If you register a `FruitRenderer`, it will be used for all `Fruit` types—including `Orange`—unless a more specific `OrangeRenderer` is also registered.
+
+Renderers must implement the `log4net.ObjectRenderer.IObjectRenderer` interface.
+
+[NOTE]
+====
+Format methods like `DebugFormat`, `InfoFormat`, etc., do *not* use Object Renderers.
+====