Made it so headers have invisible links
diff --git a/content/dormant.html b/content/dormant.html
index 1a43a9e..fa8fdfe 100644
--- a/content/dormant.html
+++ b/content/dormant.html
@@ -78,7 +78,7 @@
<div class="container">
<div class="content">
- <h3>Dormant Projects</h3>
+ <h3><a href="#dormant-projects" id="dormant-projects"></a>Dormant Projects</h3>
<p>These are Logging Services Projects that have been deemed inactive since they have seen little recent development activity or have reached end-of-life. If you wish to use any of these components, you must build them yourselves. It is best to assume that these components will not be released in the near future.</p>
<div class="row">
<div class="span4">
diff --git a/content/mailing-lists.html b/content/mailing-lists.html
index ceb9811..1afe00a 100644
--- a/content/mailing-lists.html
+++ b/content/mailing-lists.html
@@ -78,10 +78,10 @@
<div class="container">
<div class="content">
- <h1>Mailing lists</h1>
+ <h1><a href="#mailing-lists" id="mailing-lists"></a>Mailing lists</h1>
<p>These are the mailing lists that have been established for the Apache Logging Services project.</p>
<p>For questions regarding individual logging projects, please find use the mailing lists defined on the project site.</p>
-<h3>general@logging.apache.org</h3>
+<h3><a href="#generalloggingapacheorg" id="generalloggingapacheorg"></a>general@logging.apache.org</h3>
<p>General and public discussion related to the Logging project and it's children. Anyone may subscribe; only subscribers may post.</p>
<ul>
<li><a href="mailto:%67%65%6E%65%72%61%6C%40%6C%6F%67%67%69%6E%67%2E%61%70%61%63%68%65%2E%6F%72%67">Post to list</a></li>
@@ -93,7 +93,7 @@
<li><a href="http://mail-archives.apache.org/mod_mbox/logging-general/">Apache archive</a></li>
<li><a href="http://markmail.org/search/?q=list%3Aorg.apache.logging.general">Markmail archive</a></li>
</ul>
-<h3>dev@logging.apache.org</h3>
+<h3><a href="#devloggingapacheorg" id="devloggingapacheorg"></a>dev@logging.apache.org</h3>
<p>All logging projects share a common mailing list where development of each project is discussed. Please use subject tags like [log4j] when starting a new thread.</p>
<ul>
<li><a href="mailto:%64%65%76%2D%73%75%62%73%63%72%69%62%65%40%6C%6F%67%67%69%6E%67%2E%61%70%61%63%68%65%2E%6F%72%67">Subscribe to list</a></li>
@@ -105,7 +105,7 @@
<li><a href="http://mail-archives.apache.org/mod_mbox/logging-dev/">Apache archive</a></li>
<li><a href="http://markmail.org/search/?q=list%3Aorg.apache.logging.dev">Markmail archive</a></li>
</ul>
-<h3>commits@logging.apache.org</h3>
+<h3><a href="#commitsloggingapacheorg" id="commitsloggingapacheorg"></a>commits@logging.apache.org</h3>
<p>When changes are made to the source code repository, the commit messages are automatically sent to this list. Anyone may subscribe; posting is not allowed. The Reply-To is set to the logging-general list, so if you reply to a message that's where your reply is going to end up.</p>
<ul>
<li><a href="mailto:%63%6F%6D%6D%69%74%73%2D%73%75%62%73%63%72%69%62%65%40%6C%6F%67%67%69%6E%67%2E%61%70%61%63%68%65%2E%6F%72%67">Subscribe to list</a></li>
@@ -116,7 +116,7 @@
<li><a href="http://mail-archives.apache.org/mod_mbox/logging-commits/">Apache archive</a></li>
<li><a href="http://markmail.org/search/?q=list%3Aorg.apache.logging.commits">Markmail archive</a></li>
</ul>
-<h3>private@logging.apache.org</h3>
+<h3><a href="#privateloggingapacheorg" id="privateloggingapacheorg"></a>private@logging.apache.org</h3>
<p>Private list for the project management committee. It is not open to public subscription. This list should be used only for the discussion of confidential topics. As much business as possible should be conducted in public on the general list.</p>
<ul>
<li><a href="mailto:%70%72%69%76%61%74%65%40%6C%6F%67%67%69%6E%67%2E%61%70%61%63%68%65%2E%6F%72%67">Post to list</a></li>
diff --git a/content/privacy-policy.html b/content/privacy-policy.html
index 63b4da1..8197e50 100644
--- a/content/privacy-policy.html
+++ b/content/privacy-policy.html
@@ -78,7 +78,7 @@
<div class="container">
<div class="content">
- <h1>Privacy policy</h1>
+ <h1><a href="#privacy-policy" id="privacy-policy"></a>Privacy policy</h1>
<p>This document was moved <a href="https://privacy.apache.org/policies/privacy-policy-public.html">here</a></p>
</div>
diff --git a/content/security.html b/content/security.html
index e29196e..e813294 100644
--- a/content/security.html
+++ b/content/security.html
@@ -78,13 +78,13 @@
<div class="container">
<div class="content">
- <h2>Reporting New Security Problems with Apache Logging Projects</h2></h2>
+ <h2><a href="#reporting-new-security-problems-with-apache-logging-projects" id="reporting-new-security-problems-with-apache-logging-projects"></a>Reporting New Security Problems with Apache Logging Projects</h2></h2>
<p>The Apache Software Foundation takes a very active stance in eliminating security problems and denial of service attacks against its products.</p>
<p>We strongly encourage folks to report such problems to our private security mailing list first, before disclosing them in a public forum.</p>
<p>Please note that the security mailing list should only be used for reporting undisclosed security vulnerabilities and managing the process of fixing such vulnerabilities. We cannot accept regular bug reports or other queries at this address. All mail sent to this address that does not relate to an undisclosed security problem in our source code will be ignored.</p>
<p>If you need to report a bug that isn't an undisclosed security vulnerability, please use the project's issue tracker.</p>
<p>The private security mailing address is: <a href="mailto:%73%65%63%75%72%69%74%79%40%61%70%61%63%68%65%2E%6F%72%67">security@apache.org</a></p>
-<h2>Asking Questions About Known Security Problems</h2>
+<h2><a href="#asking-questions-about-known-security-problems" id="asking-questions-about-known-security-problems"></a>Asking Questions About Known Security Problems</h2>
<p>Questions about:</p>
<ol>
<li>if a vulnerability applies to your particular application</li>
@@ -92,7 +92,7 @@
<li>availability of patches and/or new releases</li>
</ol>
<p>should be addressed to the users mailing list. Please see the <a href="/mailing-lists.html">mailing lists page</a> for details of how to subscribe.</p>
-<h2>Known Security Vulnerabilities</h2>
+<h2><a href="#known-security-vulnerabilities" id="known-security-vulnerabilities"></a>Known Security Vulnerabilities</h2>
<p>Known security vulnerabilities fixed in released versions of Apache Logging projects are listed in specific pages for each project.</p>
<p>If you have encountered an unlisted security vulnerability or other unexpected behaviour that has security impact, or if the descriptions in one of the pages are incomplete, please report them privately to the Apache Security Team. Thank you.</p>
<p>Errors and Ommissions</p>
diff --git a/content/what-is-logging.html b/content/what-is-logging.html
index 26afe98..ee16a38 100644
--- a/content/what-is-logging.html
+++ b/content/what-is-logging.html
@@ -101,11 +101,11 @@
</li>
<li><a href="#conclusion">Conclusion</a></li>
</ul>
-<h1>What is logging?</h1>
+<h1><a href="#what-is-logging" id="what-is-logging"></a>What is logging?</h1>
<p>At a high level, logging is used to capture information during the run of an application. This can include different types of information about both the state of the application and inputs to the application. For example, an HTTP server may log information about incoming connections(such as an IP address).<br />
Logging can also be at different levels of verbosity, in order to allow a user of the application to not be overwhelmed with too much information.</p>
<p>Logging can be broadly classified into two categories. The two main categories of logging are debug logging and audit logging. Debug logging is generally useful for application developers who can turn on messages that an end-user does not care about - for example, if data is being parsed correctly, or if an exception is thrown. Audit logging is more interesting to system administrators. This type of data would include information such as when somebody logged in, who changed a piece of information, etc. Debug logging and audit logging are not mutually exclusive, and there can be plenty of overlap between these two categories.</p>
-<h1>What should a logging framework do?</h1>
+<h1><a href="#what-should-a-logging-framework-do" id="what-should-a-logging-framework-do"></a>What should a logging framework do?</h1>
<p>At a minimum, a logging framework needs to be able to do the following:</p>
<ul>
<li>Easily allow you to create log messages</li>
@@ -132,7 +132,7 @@
<li>Format log messages according to some user-defined pattern</li>
</ul>
<p>This is not an exhaustive list of all features that could exist. There are many different logging frameworks that exist which may implement different subsets of these features, and may also have more features than are listed here.</p>
-<h1>Log Levels and Subsystem Classification</h1>
+<h1><a href="#log-levels-and-subsystem-classification" id="log-levels-and-subsystem-classification"></a>Log Levels and Subsystem Classification</h1>
<p>When you are logging information, two of the most important things to know are the level of the log message and the subsystem that the log message is from.<br />
This allows you to determine how severe something is, as well as where it is coming from.</p>
<p>The traditional log levels are as follows(from most verbose to least verbose): TRACE DEBUG INFO WARN ERROR</p>
@@ -140,45 +140,45 @@
<p>Levels make it easy to quickly filter messages. Since more verbose messages still allow less verbose messages to be printed, you don't lose information by turning the verbosity up. When you are working on a particular subsystem, you may want that subsystem to be at the DEBUG level to see all the messages, or TRACE if there is something that you really need to see. As a general rule of thumb, when your application is in production the default level of all loggers should be at the INFO level.</p>
<p>Subsystems help to classify the data as well. In Java, this is generally done by the package that a class is in. Being able to set a particular subsystem that you are debugging to the DEBUG level(and not just a single class) is an important part of being able to easily filter information and to not overload the programmer who is debugging the application.</p>
<p>Within the Apache Logging Services projects(log4j2, log4cxx, and log4net) this subsystem classification follows the Java hierarchical approach. If you have a logger org.apache.Foo and org.apache.Bar, you can set the level of org.apache to DEBUG and both loggers will be at the DEBUG level, but can also be individually set if required. This hierarchical way of logging is not a feature that all logging frameworks have, however it is very useful if your code is organized in a way such that all classes have individual loggers and are logically separated into subsystems appropriately. This also allows for more granular control over your debug statements.</p>
-<h1>Where to put logs?</h1>
+<h1><a href="#where-to-put-logs" id="where-to-put-logs"></a>Where to put logs?</h1>
<p>Logging to different locations(sometimes called sinks) is an important part of logging frameworks. For simple applications, you may not need to do anything more complicated than just send data to stdout and/or a file. However, more complicated applications quickly need to have more flexibility in how and where they log information. Modern applications can log to web-based log aggregators in addition to a local log mechanism such as syslog.</p>
<p>By configuring these log locations through an external source such as a config file, it also makes it possible for the end-user to configure the system for their particular use-case.</p>
-<h1>Transparent Logging</h1>
+<h1><a href="#transparent-logging" id="transparent-logging"></a>Transparent Logging</h1>
<p>One of the most basic tenets of logging is that it needs to be completely transparent to your application. Your application must not care if logging is enabled or disabled: all it does is send messages to the logging framework, which then handles all of the filtering and routing required to get the message to its final destination. This also makes it possible to write unit tests that don't care about logging at all. If the logging system is not initialized, the worst that should happen is that nothing gets logged.</p>
-<h1>How to do proper logging</h1>
+<h1><a href="#how-to-do-proper-logging" id="how-to-do-proper-logging"></a>How to do proper logging</h1>
<p>Now that we understand what the normal features of logging libraries are, it’s time to talk about how to do proper logging. As we’ve mentioned before, the two main things to worry about when logging are what the level of the message is, and the classification of the log message. For the classification of the log message, this will often be the name of the class that is doing the logging. Assuming that you have a good design already, then the classification derives clearly from the name of the class and the package/namespace the class is in.</p>
<p>Choosing the level of the log message can be a bit trickier. A good rule of thumb is to leave your log messages at INFO level during normal operation, so what should we put at that level and what should be more verbose? Let’s assume that we are opening a network socket for remote communications. At the INFO level we may inform that the network subsystem is starting up and ready for work. DEBUG information could include new connections from clients with their IP/port combination, while TRACE information could be output whenever a packet comes in from a client. In addition, we may have ERROR messages if we are unable to open a socket for reading/writing.</p>
<p>By having different pieces of the data flow at different log levels, it makes it easy to quickly look at the logs and determine how serious a problem is and what the system is doing during operation.</p>
-<h1>Other things to worry about when logging</h1>
+<h1><a href="#other-things-to-worry-about-when-logging" id="other-things-to-worry-about-when-logging"></a>Other things to worry about when logging</h1>
<p>As we have seen, having a good logging framework is critical to being able to find and fix errors in applications. However, just because we have logging doesn’t mean that it is infallible. Since logging code that you insert into your application is still code that you have written, it is always possible that the log messages you get out are lying to you due to a bug in a log statement.</p>
-<h1>Features that the Apache Logging Services projects have</h1>
+<h1><a href="#features-that-the-apache-logging-services-projects-have" id="features-that-the-apache-logging-services-projects-have"></a>Features that the Apache Logging Services projects have</h1>
<p>While there are many different logging frameworks that exist for Java, C++, and .NET, there are a number of built-in features that Log4j2, Log4cxx, and Log4net have that are generally useful.</p>
-<h2>Hierarchichal Logging</h2>
+<h2><a href="#hierarchichal-logging" id="hierarchichal-logging"></a>Hierarchichal Logging</h2>
<p>As mentioned previously, hierarchical logging allows for easy grouping of subsystem information. This allows you to have fine-grained control over the information that you are logging and easily allows for one logger per-class.</p>
<p>This hierarchical logging also means that you don't need to explicitly share a sink between loggers. While it is possible to configure Log4j2 and Log4cxx to send each logger to a separate location, the parent/child relationship means that children will log their messages to any sinks that their parents have.</p>
-<h2>Location Information</h2>
+<h2><a href="#location-information" id="location-information"></a>Location Information</h2>
<p>Knowing exactly where a log statement is can be vital in order to track down the location of a log statement. Both Log4j2 and Log4cxx are able to determine the filename, class name, method name, and line number where the log message is coming from. With Log4cxx, this is able to be done at compile-time.</p>
-<h2>Static and Single-instance Loggers</h2>
+<h2><a href="#static-and-single-instance-loggers" id="static-and-single-instance-loggers"></a>Static and Single-instance Loggers</h2>
<p>All loggers that are created with Log4j2 and Log4cxx are able to be declared as static variables in your source file, eliminating the need for a dedicated instance variable of a logger per-class. A side effect of this is that there is a global logger registry, so that you can access the same logger via a static LogManager in different classes without having to pass the logger around.</p>
-<h2>Nested and Mapped Diagnostic Contexts</h2>
+<h2><a href="#nested-and-mapped-diagnostic-contexts" id="nested-and-mapped-diagnostic-contexts"></a>Nested and Mapped Diagnostic Contexts</h2>
<p>When you have multiple objects of the same type, using a static logger can be problematic when you need to only view data for one instance of the class. By providing a Nested Diagnostic Context and a Mapped Diagnostic Context, it is possible to add context information to your log statements.</p>
-<h2>Flexible Log Message Formatting</h2>
+<h2><a href="#flexible-log-message-formatting" id="flexible-log-message-formatting"></a>Flexible Log Message Formatting</h2>
<p>When sending a log message to a flat text file, it is often desirable to have the messages in a simple to understand format. This information can include data such as the date/time of the log message, the level of the message, the logger that produced the message, and the message itself. With the Log4j2 and Log4cxx PatternLayout classes, it is possible to quickly configure the logging system to output information in a convenient format.</p>
<p>Different types of log message formatting is also important when you need to send messages to different locations. The code that creates the log messages should not know anything about how the message is formatted on the backend. This allows for the same log message to be formatted in different ways with potentially different metadata - for example, JSON format for a log aggregating service, or plain text for a local configuration file.</p>
-<h2>Configuration via config file</h2>
+<h2><a href="#configuration-via-config-file" id="configuration-via-config-file"></a>Configuration via config file</h2>
<p>Both Log4j2 and Log4cxx can be configured with a configuration file in one of several different formats. While it is always possible to configure via code, configuration files make it easy to reconfigure the system without having to recompile your code. This also means it is possible to edit a configuration file and dynamically change the configuration at runtime. For example, you can turn on a logger that was previously off if you are debugging a live system.</p>
-<h2>Garbage-free(Log4j2)</h2>
+<h2><a href="#garbage-freelog4j2" id="garbage-freelog4j2"></a>Garbage-free(Log4j2)</h2>
<p>In Java, it is important to reduce the amount of time that the garbage collector takes to run. By not allocating and freeing objects, your log statements will add very little to the runtime overhead of your application.</p>
-<h2>Formatting with replacements</h2>
+<h2><a href="#formatting-with-replacements" id="formatting-with-replacements"></a>Formatting with replacements</h2>
<p>When creating a log statement, it is often slow and annoying to perform string concatenation to create a log statement. In Java, the simplest way to concatenate a string is to simply use the + operator:</p>
<p><code>log("Logging information: " + someVariable + " and the other variable is " + otherVariable);</code></p>
<p>While in C++, you can get into a chevron overload:</p>
<p><code>log("Logging information: " << someVariable << " and the other variable is " << otherVariable);</code></p>
<p>Both Log4j2 and Log4cxx allow for variable replacements in strings, such that the above log statements can both be written similar to the following:</p>
<p><code>log("Logging information: {} and the other variable is {}", someVariable, otherVariable);</code></p>
-<h2>Filtering</h2>
+<h2><a href="#filtering" id="filtering"></a>Filtering</h2>
<p>When you have many different log messages that you are trying to make sense of, it can be difficult to focus on the correct piece of information. Because of this, it is possible to configure both Log4j2 and Log4cxx to filter certain messages based off of various attributes, such as a text string that is contained within the log message. Since these filters are also able to be configured through the confgiuration file, adding or removing filters is a simple operation.</p>
-<h1>Conclusion</h1>
+<h1><a href="#conclusion" id="conclusion"></a>Conclusion</h1>
<p>Logging is a rather complicated topic that covers many different aspects. While different applications will have different requirements for their log statements, the projects of the Apache Logging Services Commitee provide a generic and widely applicable implemenation of logging for all kinds of applications.</p>
</div>
diff --git a/sources/src/main/jbake/custom.properties b/sources/src/main/jbake/custom.properties
index 0cb72e6..b2d69de 100644
--- a/sources/src/main/jbake/custom.properties
+++ b/sources/src/main/jbake/custom.properties
@@ -9,5 +9,5 @@
destination.folder=../content
-markdown.extensions=TOC
+markdown.extensions=TOC,ANCHORLINKS,EXTANCHORLINKS
