jackrabbit-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mreut...@apache.org
Subject svn commit: r1835390 [7/23] - in /jackrabbit/site/live/oak/docs: ./ architecture/ coldstandby/ features/ nodestore/ nodestore/document/ nodestore/segment/ oak-mongo-js/ oak_api/ plugins/ query/ security/ security/accesscontrol/ security/authentication/...
Date Mon, 09 Jul 2018 08:53:19 GMT
Modified: jackrabbit/site/live/oak/docs/nodestore/segment/tar.html
URL: http://svn.apache.org/viewvc/jackrabbit/site/live/oak/docs/nodestore/segment/tar.html?rev=1835390&r1=1835389&r2=1835390&view=diff
==============================================================================
--- jackrabbit/site/live/oak/docs/nodestore/segment/tar.html (original)
+++ jackrabbit/site/live/oak/docs/nodestore/segment/tar.html Mon Jul  9 08:53:17 2018
@@ -1,13 +1,13 @@
 <!DOCTYPE html>
 <!--
- | Generated by Apache Maven Doxia Site Renderer 1.7.4 at 2018-05-24 
+ | Generated by Apache Maven Doxia Site Renderer 1.8.1 at 2018-07-09 
  | Rendered using Apache Maven Fluido Skin 1.6
 -->
 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
   <head>
     <meta charset="UTF-8" />
     <meta name="viewport" content="width=device-width, initial-scale=1.0" />
-    <meta name="Date-Revision-yyyymmdd" content="20180524" />
+    <meta name="Date-Revision-yyyymmdd" content="20180709" />
     <meta http-equiv="Content-Language" content="en" />
     <title>Jackrabbit Oak &#x2013; Structure of TAR files</title>
     <link rel="stylesheet" href="../../css/apache-maven-fluido-1.6.min.css" />
@@ -136,7 +136,7 @@
 
       <div id="breadcrumbs">
         <ul class="breadcrumb">
-        <li id="publishDate">Last Published: 2018-05-24<span class="divider">|</span>
+        <li id="publishDate">Last Published: 2018-07-09<span class="divider">|</span>
 </li>
           <li id="projectVersion">Version: 1.10-SNAPSHOT</li>
         </ul>
@@ -240,7 +240,8 @@
   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.
---><h1>Structure of TAR files</h1>
+-->
+<h1>Structure of TAR files</h1>
 <p>Here is described the physical layout of a TAR file as used by Apache Oak. First, a brief introduction of the TAR format is given. Next, more details are provided about the low level information that is written in TAR entries. Finally, it&#x2019;s described how Oak saves a graph data structure inside the TAR file and how this representation is optimized for fast retrieval.</p>
 <div class="section">
 <h2><a name="Organization_of_a_TAR_file"></a>Organization of a TAR file</h2>
@@ -248,66 +249,82 @@
 <p>Logically speaking, a TAR file is a linear sequence of entries. Every entry is represented by two or more blocks. The first block always contains the entry header. Subsequent blocks store the content of the file.</p>
 <p><img src="tar.png" alt="Overview of a TAR file" /></p>
 <p>The entry header is composed of the following fields:</p>
-
 <ul>
-  
+
 <li>
-<p>file name (100 bytes) - name of the file stored in this entry.</p></li>
-  
+
+<p>file name (100 bytes) - name of the file stored in this entry.</p>
+</li>
 <li>
-<p>file mode (8 bytes) - string representation of the octal file mode.</p></li>
-  
+
+<p>file mode (8 bytes) - string representation of the octal file mode.</p>
+</li>
 <li>
-<p>owner&#x2019;s numeric ID (8 bytes) - string representation of the user ID of the  owner of the file.</p></li>
-  
+
+<p>owner&#x2019;s numeric ID (8 bytes) - string representation of the user ID of the owner of the file.</p>
+</li>
 <li>
-<p>group&#x2019;s numeric ID (8 bytes) - string representation of the group ID of the  owner of the file.</p></li>
-  
+
+<p>group&#x2019;s numeric ID (8 bytes) - string representation of the group ID of the owner of the file.</p>
+</li>
 <li>
-<p>file size (12 bytes) - string representation of the octal size of the file.</p></li>
-  
+
+<p>file size (12 bytes) - string representation of the octal size of the file.</p>
+</li>
 <li>
-<p>last modification time (12 bytes) - string representation of the octal time  stamp when the file was last modified.</p></li>
-  
+
+<p>last modification time (12 bytes) - string representation of the octal time stamp when the file was last modified.</p>
+</li>
 <li>
-<p>checksum (8 bytes) - checksum for the header data.</p></li>
-  
+
+<p>checksum (8 bytes) - checksum for the header data.</p>
+</li>
 <li>
-<p>file type (1 byte) - type of the file stored in the entry. This field  specifies if the file is a regular file, a hard link or a symbolic link.</p></li>
-  
+
+<p>file type (1 byte) - type of the file stored in the entry. This field specifies if the file is a regular file, a hard link or a symbolic link.</p>
+</li>
 <li>
-<p>name of linked file (1 byte) - in case the file stored in the entry is a link,  this field stores the name of the file pointed to by the link.</p></li>
+
+<p>name of linked file (1 byte) - in case the file stored in the entry is a link, this field stores the name of the file pointed to by the link.</p>
+</li>
 </ul></div>
 <div class="section">
 <h2><a name="The_TAR_file_as_used_by_Oak"></a>The TAR file as used by Oak</h2>
 <p>Some fields are not used by Oak. In particular, Oak sets the file mode, the owner&#x2019;s numeric ID, the group&#x2019;s numeric ID, the checksum, and the name of linked file to uninteresting values. The only meaningful values assigned to the fields of the entry header are:</p>
-
 <ul>
-  
+
 <li>
-<p>file name: the name of the data file. There are different data files used by  Oak. They are described below.</p></li>
-  
+
+<p>file name: the name of the data file. There are different data files used by Oak. They are described below.</p>
+</li>
 <li>
-<p>file size: the size of the data file. The value assigned to this field is  trivially computed from the amount of information stored in the data file.</p></li>
-  
+
+<p>file size: the size of the data file. The value assigned to this field is trivially computed from the amount of information stored in the data file.</p>
+</li>
 <li>
-<p>last modification time: the time stamp when the entry was written.</p></li>
+
+<p>last modification time: the time stamp when the entry was written.</p>
+</li>
 </ul>
 <p>There are four kinds of files stored in a TAR file:</p>
-
 <ul>
-  
+
 <li>
-<p>segments: this type of file contains data about a segment in the segment  store. This kind of file has a file name in the form <tt>UUID.CRC2</tt>, where <tt>UUID</tt>  is a 128 bit UUID represented as an hexadecimal string and <tt>CRC2</tt> is a zero-  padded numeric string representing the CRC2 checksum of the raw segment data.</p></li>
-  
+
+<p>segments: this type of file contains data about a segment in the segment store. This kind of file has a file name in the form <tt>UUID.CRC2</tt>, where <tt>UUID</tt> is a 128 bit UUID represented as an hexadecimal string and <tt>CRC2</tt> is a zero- padded numeric string representing the CRC2 checksum of the raw segment data.</p>
+</li>
 <li>
-<p>binary references: this file has a name ending in <tt>.brf</tt> and represents a  catalog of blobs (i.e. value records) referenced by segments in this TAR file.  This catalog is indexed by the generation of the segments it contains.</p></li>
-  
+
+<p>binary references: this file has a name ending in <tt>.brf</tt> and represents a catalog of blobs (i.e. value records) referenced by segments in this TAR file. This catalog is indexed by the generation of the segments it contains.</p>
+</li>
 <li>
-<p>graph: this file has a name ending in <tt>.gph</tt> and contains the segment graph  of all the segments in this tar file. The graph is represented as an adjacency  list of UUIDs.</p></li>
-  
+
+<p>graph: this file has a name ending in <tt>.gph</tt> and contains the segment graph of all the segments in this tar file. The graph is represented as an adjacency list of UUIDs.</p>
+</li>
 <li>
-<p>index: this file has a name ending in <tt>.idx</tt> and contains a sorted list of  every segment contained in the TAR file.</p></li>
+
+<p>index: this file has a name ending in <tt>.idx</tt> and contains a sorted list of every segment contained in the TAR file.</p>
+</li>
 </ul></div>
 <div class="section">
 <h2><a name="Oak_TAR_file_layout"></a>Oak TAR file layout</h2>
@@ -324,67 +341,66 @@
 <p>The list of segments referenced by a data segment will end up in the graph file. To speed up the process of locating a segment in the list of referenced segment, this list is maintained ordered.</p>
 <p>The data segment file is divided in two parts. The first is the header and the second contains the actual records contained in this segment.</p>
 <p>The data segment header is divided in three parts:</p>
-
 <ul>
-  
+
 <li>
+
 <p>a fixed part (32 bytes) containing:</p>
-  
 <ul>
-    
-<li>a magic number (3 bytes): identifies the beginning of a data segment.</li>
-  </ul>
-  
-<ul>
-    
-<li>version (1 byte): the segment version.</li>
-  </ul>
-  
-<ul>
-    
-<li>empty bytes (6 bytes): reserved for future use.</li>
-  </ul>
-  
-<ul>
-    
-<li>generation (4 bytes): generation of the segment, serialized as a big endian  integer.</li>
-  </ul>
-  
-<ul>
-    
-<li>number of references (4 bytes): number of references to external segments,  serialized as a big endian integer.</li>
-  </ul>
-  
-<ul>
-    
-<li>number of records (4 bytes): number of records in this segment, serialized  as a big endian integer.</li>
-  </ul>
-  
-<ul>
-    
-<li>empty bytes (10 bytes): reserved for future use.</li>
-  </ul></li>
-  
+
 <li>
-<p>second part of the header is a variable list of references to external segments.  Here there will be a list of UUIDs - one per referenced segment - matching the  number of references specified in the first part of the header.</p></li>
-  
+
+<p>a magic number (3 bytes): identifies the beginning of a data segment.</p>
+</li>
 <li>
-<p>the third and last part of the header consists of a list of record header  entries, matching the number of records specified in the first part of the  header. Each record header consists of:</p>
-  
-<ul>
-    
-<li>record number (4 bytes), serialized as a big endian integer.</li>
-  </ul>
-  
-<ul>
-    
-<li>record type (1 byte): can be one of <i>LEAF</i>, <i>BRANCH</i>, <i>BUCKET</i>, <i>LIST</i>,  <i>VALUE</i>, <i>BLOCK</i>, <i>TEMPLATE</i>, <i>NODE</i> or <i>BLOB_ID</i>.</li>
-  </ul>
-  
+
+<p>version (1 byte): the segment version.</p>
+</li>
+<li>
+
+<p>empty bytes (6 bytes): reserved for future use.</p>
+</li>
+<li>
+
+<p>generation (4 bytes): generation of the segment, serialized as a big endian integer.</p>
+</li>
+<li>
+
+<p>number of references (4 bytes): number of references to external segments, serialized as a big endian integer.</p>
+</li>
+<li>
+
+<p>number of records (4 bytes): number of records in this segment, serialized as a big endian integer.</p>
+</li>
+<li>
+
+<p>empty bytes (10 bytes): reserved for future use.</p>
+</li>
+</ul>
+</li>
+<li>
+
+<p>second part of the header is a variable list of references to external segments. Here there will be a list of UUIDs - one per referenced segment - matching the number of references specified in the first part of the header.</p>
+</li>
+<li>
+
+<p>the third and last part of the header consists of a list of record header entries, matching the number of records specified in the first part of the header. Each record header consists of:</p>
 <ul>
-    
-<li>record offset (4 bytes), serialized as a big endian integer: offset of the  record counting from the end of the segment. The actual position of the  record can be obtained by computing <tt>(segment size - offset)</tt>.</li>
-  </ul></li>
+
+<li>
+
+<p>record number (4 bytes), serialized as a big endian integer.</p>
+</li>
+<li>
+
+<p>record type (1 byte): can be one of <i>LEAF</i>, <i>BRANCH</i>, <i>BUCKET</i>, <i>LIST</i>, <i>VALUE</i>, <i>BLOCK</i>, <i>TEMPLATE</i>, <i>NODE</i> or <i>BLOB_ID</i>.</p>
+</li>
+<li>
+
+<p>record offset (4 bytes), serialized as a big endian integer: offset of the record counting from the end of the segment. The actual position of the record can be obtained by computing <tt>(segment size - offset)</tt>.</p>
+</li>
+</ul>
+</li>
 </ul>
 <p>After the segment header, the actual records are stored, at the offsets advertised in the corresponding record header stored in the last part of the segment header.</p>
 <p>See <a href="records.html">Segments and records</a> for description of the various record types and their format.</p></div>
@@ -394,120 +410,143 @@
 <p>The format of the binary references file is optimized for reading. The file is stored in reverse order to maintain the most important information at the end of the file. This strategy is inline with the overall layout of the entries in the TAR file.</p>
 <p>The binary references file is divided in two parts. The first is a header and the second contains the real data in the catalog.</p>
 <p>The binary references header contains the following fields:</p>
-
 <ul>
-  
+
 <li>
-<p>a magic number (4 bytes): identifies the beginning of a binary references file.</p></li>
-  
+
+<p>a magic number (4 bytes): identifies the beginning of a binary references file.</p>
+</li>
 <li>
-<p>size of the whole binary references mapping (4 bytes): number of bytes occupied  by the entire structure holding binary references (per generation, per segment).</p></li>
-  
+
+<p>size of the whole binary references mapping (4 bytes): number of bytes occupied by the entire structure holding binary references (per generation, per segment).</p>
+</li>
 <li>
-<p>number of generations (4 bytes): number of different generations of the segments  which refer blobs.</p></li>
-  
+
+<p>number of generations (4 bytes): number of different generations of the segments which refer blobs.</p>
+</li>
 <li>
-<p>checksum (4 bytes): a CRC2 checksum of the content of the binary references  file.</p></li>
+
+<p>checksum (4 bytes): a CRC2 checksum of the content of the binary references file.</p>
+</li>
 </ul>
 <p>Immediately after the graph header, the index data is stored. The storage scheme used is the following:</p>
-
 <ul>
-  
+
 <li>
-<p>generation of all the following segments.</p></li>
-  
+
+<p>generation of all the following segments.</p>
+</li>
 <li>
-<p>number of segment to binary references mappings for the current generation.</p></li>
-  
+
+<p>number of segment to binary references mappings for the current generation.</p>
+</li>
 <li>
+
 <p>for each mapping we have:</p>
-  
-<ul>
-    
-<li>UUID of the referencing segment.</li>
-  </ul>
-  
-<ul>
-    
-<li>number of referenced blobs.</li>
-  </ul>
-  
 <ul>
-    
-<li>an unordered enumeration of blob ids representing blobs referenced by the  current segment.</li>
-  </ul></li>
+
+<li>
+
+<p>UUID of the referencing segment.</p>
+</li>
+<li>
+
+<p>number of referenced blobs.</p>
+</li>
+<li>
+
+<p>an unordered enumeration of blob ids representing blobs referenced by the current segment.</p>
+</li>
+</ul>
+</li>
 </ul></div>
 <div class="section">
 <h2><a name="Graph_files"></a>Graph files</h2>
 <p>The graph file represents the relationships between segments stored inside or outside the TAR file. The graph is stored as an adjacency list of UUIDs, where each UUID represents a segment. Like the binary references file, the graph file is also stored backwards.</p>
 <p>The content of the graph file is divided in two parts: a graph header and a graph adjacency list.</p>
 <p>The graph header contains the following fields:</p>
-
 <ul>
-  
+
 <li>
-<p>a magic number (4 bytes): identifies the beginning of a graph file.</p></li>
-  
+
+<p>a magic number (4 bytes): identifies the beginning of a graph file.</p>
+</li>
 <li>
-<p>size of the graph adjacency list (4 bytes): number of bytes occupied by the  graph adjacency list.</p></li>
-  
+
+<p>size of the graph adjacency list (4 bytes): number of bytes occupied by the graph adjacency list.</p>
+</li>
 <li>
-<p>number of entries (4 bytes): how many adjacency lists are stored.</p></li>
-  
+
+<p>number of entries (4 bytes): how many adjacency lists are stored.</p>
+</li>
 <li>
-<p>checksum (4 bytes): a CRC2 checksum of the content of the graph file.</p></li>
+
+<p>checksum (4 bytes): a CRC2 checksum of the content of the graph file.</p>
+</li>
 </ul>
 <p>Immediately after the graph header, the graph adjacency list is stored. The storage scheme used is the following:</p>
-
 <ul>
-  
+
 <li>
-<p>UUID of the source segment.</p></li>
-  
+
+<p>UUID of the source segment.</p>
+</li>
 <li>
-<p>size of the adjacency list of the source segment.</p></li>
-  
+
+<p>size of the adjacency list of the source segment.</p>
+</li>
 <li>
-<p>an unordered enumeration of UUIDs representing target segments referenced by  the source segment.</p></li>
+
+<p>an unordered enumeration of UUIDs representing target segments referenced by the source segment.</p>
+</li>
 </ul></div>
 <div class="section">
 <h2><a name="Index_files"></a>Index files</h2>
 <p>The index file is an ordered list of references to the entries contained in the TAR file. The references are ordered by UUID and they point to the position in the file where the entry is stored. Like the graph file, the index file is also stored backwards.</p>
 <p>The index file is divided in two parts. The first is an index header, the second contains the real data about the index.</p>
 <p>The index header contains the following fields:</p>
-
 <ul>
-  
+
 <li>
-<p>a magic number (4 bytes): identifies the beginning of an index file.</p></li>
-  
+
+<p>a magic number (4 bytes): identifies the beginning of an index file.</p>
+</li>
 <li>
-<p>size for the index (4 bytes): number of bytes occupied by the index data. This  size also contains padding bytes that are added to the index to make it align  with the TAR block boundary.</p></li>
-  
+
+<p>size for the index (4 bytes): number of bytes occupied by the index data. This size also contains padding bytes that are added to the index to make it align with the TAR block boundary.</p>
+</li>
 <li>
-<p>number of entries (4 bytes): how many entries the index contains.</p></li>
-  
+
+<p>number of entries (4 bytes): how many entries the index contains.</p>
+</li>
 <li>
-<p>checksum (4 bytes): a CRC32 checksum of the content of the index file.</p></li>
+
+<p>checksum (4 bytes): a CRC32 checksum of the content of the index file.</p>
+</li>
 </ul>
 <p>After the header, the content of the index starts. For every entry contained in the index, the following information is stored:</p>
-
 <ul>
-  
+
 <li>
-<p>the most significant bits of the UUID (8 bytes).</p></li>
-  
+
+<p>the most significant bits of the UUID (8 bytes).</p>
+</li>
 <li>
-<p>the least significant bits of the UUID (8 bytes).</p></li>
-  
+
+<p>the least significant bits of the UUID (8 bytes).</p>
+</li>
 <li>
-<p>the offset in the TAR file where the TAR entry containing the segment is  located.</p></li>
-  
+
+<p>the offset in the TAR file where the TAR entry containing the segment is located.</p>
+</li>
 <li>
-<p>the size of the entry in the TAR file.</p></li>
-  
+
+<p>the size of the entry in the TAR file.</p>
+</li>
 <li>
-<p>the generation of the entry.</p></li>
+
+<p>the generation of the entry.</p>
+</li>
 </ul>
 <p>Since the entries in the index are sorted by UUID, and since the UUIDs assigned to the entries are uniformly distributed, when searching an entry by its UUID an efficient algorithm called interpolation search can be used. This algorithm is a variation of binary search. While in binary search the search space (in this case, the array of entry) is halved at every iteration, interpolation search exploits the distribution of the keys to remove a portion of the search space that is potentially bigger than the half of it. Interpolation search is a more natural approximation of the way a person searches in a phone book. If the name to search begins with the letter T, in example, it makes no sense to open the phone book at the half. It is way more efficient, instead, to open the phone book close to the bottom quarter, since names starting with the letter T are more likely to be distributed in that part of the phone book.</p></div>
         </div>

Modified: jackrabbit/site/live/oak/docs/nodestore/segmentmk.html
URL: http://svn.apache.org/viewvc/jackrabbit/site/live/oak/docs/nodestore/segmentmk.html?rev=1835390&r1=1835389&r2=1835390&view=diff
==============================================================================
--- jackrabbit/site/live/oak/docs/nodestore/segmentmk.html (original)
+++ jackrabbit/site/live/oak/docs/nodestore/segmentmk.html Mon Jul  9 08:53:17 2018
@@ -1,13 +1,13 @@
 <!DOCTYPE html>
 <!--
- | Generated by Apache Maven Doxia Site Renderer 1.7.4 at 2018-05-24 
+ | Generated by Apache Maven Doxia Site Renderer 1.8.1 at 2018-07-09 
  | Rendered using Apache Maven Fluido Skin 1.6
 -->
 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
   <head>
     <meta charset="UTF-8" />
     <meta name="viewport" content="width=device-width, initial-scale=1.0" />
-    <meta name="Date-Revision-yyyymmdd" content="20180524" />
+    <meta name="Date-Revision-yyyymmdd" content="20180709" />
     <meta http-equiv="Content-Language" content="en" />
     <title>Jackrabbit Oak &#x2013; Segment Storage Design Overview</title>
     <link rel="stylesheet" href="../css/apache-maven-fluido-1.6.min.css" />
@@ -136,7 +136,7 @@
 
       <div id="breadcrumbs">
         <ul class="breadcrumb">
-        <li id="publishDate">Last Published: 2018-05-24<span class="divider">|</span>
+        <li id="publishDate">Last Published: 2018-07-09<span class="divider">|</span>
 </li>
           <li id="projectVersion">Version: 1.10-SNAPSHOT</li>
         </ul>
@@ -240,31 +240,33 @@
    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.
-  --><h1>Segment Storage Design Overview</h1>
+  -->
+<h1>Segment Storage Design Overview</h1>
 <p><i>NOTE:</i> The information on this page applies to an older version of the TarMK and is mainly of historical interest. For the documentation of the current versions see <a href="segment/overview.html">Oak Segment Tar</a>.</p>
 <p>The SegmentNodeStore is an Oak storage backend that stores content as various types of <i>records</i> within larger <i>segments</i>. One or more <i>journals</i> are used to track the latest state of the repository. In the Tar implementation only one &#x201c;root&#x201d; journal is used.</p>
 <p>The SegmentNodeStore was designed from the ground up based on the following key principles:</p>
-
 <ul>
-  
+
 <li>
-<p>Immutability. Segments are immutable, which makes is easy to cache frequently accessed segments. This also makes it less likely for programming or system errors to cause repository inconsistencies, and simplifies features like backups or master-slave clustering.</p></li>
-  
+
+<p>Immutability. Segments are immutable, which makes is easy to cache frequently accessed segments. This also makes it less likely for programming or system errors to cause repository inconsistencies, and simplifies features like backups or master-slave clustering.</p>
+</li>
 <li>
-<p>Compactness. The formatting of records is optimized for size to reduce IO costs and to fit as much content in caches as possible. A node stored in SegmentNodeStore typically consumes only a fraction of the size it would as a bundle in Jackrabbit Classic.</p></li>
-  
+
+<p>Compactness. The formatting of records is optimized for size to reduce IO costs and to fit as much content in caches as possible. A node stored in SegmentNodeStore typically consumes only a fraction of the size it would as a bundle in Jackrabbit Classic.</p>
+</li>
 <li>
-<p>Locality. Segments are written so that related records, like a node and its immediate children, usually end up stored in the same segment. This makes tree traversals very fast and avoids most cache misses for typical clients that access more than one related node per session.</p></li>
+
+<p>Locality. Segments are written so that related records, like a node and its immediate children, usually end up stored in the same segment. This makes tree traversals very fast and avoids most cache misses for typical clients that access more than one related node per session.</p>
+</li>
 </ul>
 <p>This document describes the overall design of the SegmentNodeStore. See the source code and javadocs in <tt>org.apache.jackrabbit.oak.plugins.segment</tt> for full details.</p>
 <h1>Segments</h1>
 <p>The content tree and all its revisions are stored in a collection of immutable segments. Each segment is identified by a UUID and typically contains a continuous subset of the content tree, for example a node with its properties and closest child nodes. Some segments might also be used to store commonly occurring property values or other shared data. Segments can be to up to 256KiB in size.</p>
 <p>Segments come in two types: data and bulk segments. The type of a segment is encoded in its UUID and can thus be determined already before reading the segment. The following bit patterns are used (each <tt>x</tt> represents four random bits):</p>
-
 <ul>
-  
+
 <li><tt>xxxxxxxx-xxxx-4xxx-axxx-xxxxxxxxxxxx</tt> data segment UUID</li>
-  
 <li><tt>xxxxxxxx-xxxx-4xxx-bxxx-xxxxxxxxxxxx</tt> bulk segment UUID</li>
 </ul>
 <p>(This encoding makes segment UUIDs appear as syntactically valid version 4 random UUIDs specified in RFC 4122.)</p>
@@ -272,22 +274,27 @@
 <h2><a name="Bulk_segments"></a>Bulk segments</h2>
 <p>Bulk segments contain raw binary data, interpreted simply as a sequence of block records with no headers or other extra metadata:</p>
 
-<div class="source">
-<div class="source"><pre class="prettyprint">[block 1] [block 2] ... [block N]
+<div>
+<div>
+<pre class="source">[block 1] [block 2] ... [block N]
 </pre></div></div>
+
 <p>A bulk segment whose length is <tt>n</tt> bytes consists of <tt>n div 4096</tt> block records of 4KiB each followed possibly a block record of <tt>n mod 4096</tt> bytes, if there still are remaining bytes in the segment. The structure of a bulk segment can thus be determined based only on the segment length.</p></div>
 <div class="section">
 <h2><a name="Data_segments"></a>Data segments</h2>
 <p>A data segment can contain any types of records, may refer to content in other segments, and comes with a segment header that guides the parsing of the segment. The overall structure of a data segment is:</p>
 
-<div class="source">
-<div class="source"><pre class="prettyprint">[segment header] [record 1] [record 2] ... [record N]
+<div>
+<div>
+<pre class="source">[segment header] [record 1] [record 2] ... [record N]
 </pre></div></div>
+
 <p>The header and each record is zero-padded to make their size a multiple of four bytes and to align the next record at a four-byte boundary.</p>
 <p>The segment header consists of the following fields:</p>
 
-<div class="source">
-<div class="source"><pre class="prettyprint">+--------+--------+--------+--------+--------+--------+--------+--------+
+<div>
+<div>
+<pre class="source">+--------+--------+--------+--------+--------+--------+--------+--------+
 | magic bytes: &quot;0aK&quot; ASCII |version |reserved|idcount |rootcount        |
 +--------+--------+--------+--------+--------+--------+--------+--------+
 | blobrefcount    | reserved (set to 0)                                 |
@@ -308,6 +315,7 @@
 |                                            | padding (set to 0)       |
 +--------+--------+--------+--------+--------+--------+--------+--------+
 </pre></div></div>
+
 <p>The first three bytes of a segment always contain the ASCII string &#x201c;0aK&#x201d;, which is intended to make the binary segment data format easily detectable. The next byte indicates the version of segment format, and is set to 10 for all segments that follow the format described here.</p>
 <p>The <tt>idcount</tt> byte indicates how many other segments are referenced by records within this segment. The identifiers of those segments are listed starting at offset 16 of the segment header. This lookup table of up to 255 segment identifiers is used to optimize garbage collection and to avoid having to repeat the 16-byte UUIDs whenever references to records in other segments are made.</p>
 <p>The 16-bit <tt>rootcount</tt> field indicates the number of root record references that follow after the segment identifier lookup table. The root record references are a debugging and recovery aid, that are not needed during normal operation. They identify the types and locations of those records within this segment that are not accessible by following references in other records within this segment. <s>These root references give enough context for parsing all records within a segment without any external information.</s> See <a class="externalLink" href="https://issues.apache.org/jira/browse/OAK-2498">OAK-2498</a>.</p>
@@ -324,11 +332,13 @@
 <p>The content inside a segment is divided in records of different types: blocks, lists, maps, values, templates and nodes. These record types and their internal structures are described in subsections below.</p>
 <p>Each record is uniquely addressable by its location within the segment and the UUID of that segment. A single segment can contain up to 256KiB of data and and references to up to 256 segments (including itself). Since all records are aligned at four-byte boundaries, 16 bits are needed to address all possible record locations within a segment. Thus only three bytes are needed to store a reference to any record in any segment (1 byte to identify the segment, 2 bytes for the record offset):</p>
 
-<div class="source">
-<div class="source"><pre class="prettyprint">+--------+--------+--------+
+<div>
+<div>
+<pre class="source">+--------+--------+--------+
 | refid  | offset          |
 +--------+--------+--------+
 </pre></div></div>
+
 <p>The <tt>refid</tt> filed is the number of the referenced segment identifier, with refid zero interpreted as a reference to the current segment and refids 1-255 the segment identifiers stored in the lookup table in the segment header.</p></div>
 <div class="section">
 <h2><a name="Block_records"></a>Block records</h2>
@@ -338,8 +348,9 @@
 <p>List records are used as components of more complex record types. Lists are used for storing arrays of values for multi-valued properties and sequences of blocks for large binary values.</p>
 <p>The list of references is split into pieces of up to 255 references each and those pieces are stored as records. If there are more than 255 pieces like that, then a higher-level list is created of references to those pieces. This process is continued until the resulting list has less than 255 entries.</p>
 
-<div class="source">
-<div class="source"><pre class="prettyprint">+--------+--------+--------+-----+
+<div>
+<div>
+<pre class="source">+--------+--------+--------+-----+
 | sub-list ID 1            | ... |
 +--------+--------+--------+-----+
   |
@@ -348,6 +359,7 @@
 | record ID 1              | ... | record ID 255            |
 +--------+--------+--------+-----+--------+--------+--------+
 </pre></div></div>
+
 <p>The result is a hierarchically stored immutable list where each element can be accessed in O(log N) time and the size overhead of updating or appending list elements (and thus creating a new immutable list) is also O(log N).</p></div>
 <div class="section">
 <h2><a name="Map_records"></a>Map records</h2>
@@ -360,32 +372,32 @@
 <p>Value records are byte arrays used for storing all names and values of the content tree. Since item names can be thought of as name values and since all JCR and Oak values can be expressed in binary form (strings encoded in UTF-8), it is easiest to simply use that form for storing all values. The size overhead of such a form for small value types like booleans or dates is amortized by the facts that those types are used only for a minority of values in typical content trees and that repeating copies of a value can be stored just once.</p>
 <p>There are four types of value records: small, medium, long and external. The small- and medium-sized values are stored in inline form, prepended by one or two bytes that indicate the length of the value. Long values of up to two exabytes (2^61) are stored as a list of block records. Finally an external value record contains the length of the value and a string reference (up to 4kB in length) to some external storage location.</p>
 <p>The type of a value record is encoded in the high-order bits of the first byte of the record. These bit patterns are:</p>
-
 <ul>
-  
+
 <li><tt>0xxxxxxx</tt>: small value, length (0 - 127 bytes) encoded in 7 bits</li>
-  
 <li><tt>10xxxxxx</tt>: medium value length (128 - 16511 bytes) encoded in 6 + 8 bits</li>
-  
 <li><tt>110xxxxx</tt>: long value, length (up to 2^61 bytes) encoded in 5 + 7*8 bits</li>
-  
 <li><tt>1110xxxx</tt>: external value, reference string length encoded in 4 + 8 bits</li>
 </ul></div>
 <div class="section">
 <h2><a name="Template_records"></a>Template records</h2>
 <p>A template record describes the common structure of a family of related nodes. Since the structures of most nodes in a typical content tree fall into a small set of common templates, it makes sense to store such templates separately instead of repeating that information separately for each node. For example, the property names and types as well as child node names of all nt:file nodes are typically the same. The presence of mixins and different subtypes increases the number of different templates, but they&#x2019;re typically still far fewer than nodes in the repository.</p>
 <p>A template record consists of a set of up to N (exact size TBD, N ~ 256) property name and type pairs. Additionally, since nodes that are empty or contain just a single child node are most common, a template record also contains information whether the node has zero, one or many child nodes. In case of a single child node, the template also contains the name of that node. For example, the template for typical mix:versionable nt:file nodes would be (using CND-like notation):</p>
+<ul>
 
-<div class="source">
-<div class="source"><pre class="prettyprint">- jcr:primaryType (NAME)
-- jcr:mixinTypes (NAME) multiple
-- jcr:created (DATE)
-- jcr:uuid (STRING)
-- jcr:versionHistory (REFERENCE)
-- jcr:predecessors (REFERENCE) multiple
-- jcr:baseVersion (REFERENCE)
-+ jcr:content
-</pre></div></div>
+<li>jcr:primaryType (NAME)
+<ul>
+
+<li>jcr:mixinTypes (NAME) multiple</li>
+<li>jcr:created (DATE)</li>
+<li>jcr:uuid (STRING)</li>
+<li>jcr:versionHistory (REFERENCE)</li>
+<li>jcr:predecessors (REFERENCE) multiple</li>
+<li>jcr:baseVersion (REFERENCE)</li>
+<li>jcr:content</li>
+</ul>
+</li>
+</ul>
 <p>The names used in a template are stored as separate value records and included by reference. This way multiple templates that for example all contain the &#x201c;jcr:primaryType&#x201d; property name don&#x2019;t need to repeatedly store it.</p></div>
 <div class="section">
 <h2><a name="Node_records"></a>Node records</h2>
@@ -394,25 +406,16 @@
 <p>A node that contains more than N properties or M child nodes (exact size TBD, M ~ 1k) is stored differently, using map records for the properties and child nodes. This way a node can become arbitrarily large and still remain reasonably efficient to access and modify. The main downside of this alternative storage layout is that the ordering of child nodes is lost.</p>
 <h1>Tar</h1>
 <p>TODO:</p>
-
 <ul>
-  
+
 <li>tar entry checksums</li>
-  
 <li>graph and index entries</li>
-  
 <li>recovery mechanism</li>
-  
 <li>tar generations / cleanup</li>
-  
 <li>journal.log</li>
-  
 <li>compaction</li>
-  
 <li>cleanup</li>
-  
 <li>backup</li>
-  
 <li>slow startup / journal.log</li>
 </ul></div>
         </div>

Modified: jackrabbit/site/live/oak/docs/oak-mongo-js/index.html
URL: http://svn.apache.org/viewvc/jackrabbit/site/live/oak/docs/oak-mongo-js/index.html?rev=1835390&r1=1835389&r2=1835390&view=diff
==============================================================================
--- jackrabbit/site/live/oak/docs/oak-mongo-js/index.html (original)
+++ jackrabbit/site/live/oak/docs/oak-mongo-js/index.html Mon Jul  9 08:53:17 2018
@@ -56,7 +56,7 @@
 <br class="clear">
 
 <footer>
-    Documentation generated by <a href="https://github.com/jsdoc3/jsdoc">JSDoc 3.3.2</a> on Thu May 24 2018 12:33:47 GMT+0200 (CEST)
+    Documentation generated by <a href="https://github.com/jsdoc3/jsdoc">JSDoc 3.3.2</a> on Mon Jul 09 2018 10:50:53 GMT+0200 (CEST)
 </footer>
 
 <script> prettyPrint(); </script>

Modified: jackrabbit/site/live/oak/docs/oak-mongo-js/oak-mongo.js.html
URL: http://svn.apache.org/viewvc/jackrabbit/site/live/oak/docs/oak-mongo-js/oak-mongo.js.html?rev=1835390&r1=1835389&r2=1835390&view=diff
==============================================================================
--- jackrabbit/site/live/oak/docs/oak-mongo-js/oak-mongo.js.html (original)
+++ jackrabbit/site/live/oak/docs/oak-mongo-js/oak-mongo.js.html Mon Jul  9 08:53:17 2018
@@ -1105,7 +1105,7 @@ var oak = (function(global){
 <br class="clear">
 
 <footer>
-    Documentation generated by <a href="https://github.com/jsdoc3/jsdoc">JSDoc 3.3.2</a> on Thu May 24 2018 12:33:47 GMT+0200 (CEST)
+    Documentation generated by <a href="https://github.com/jsdoc3/jsdoc">JSDoc 3.3.2</a> on Mon Jul 09 2018 10:50:53 GMT+0200 (CEST)
 </footer>
 
 <script> prettyPrint(); </script>

Modified: jackrabbit/site/live/oak/docs/oak-mongo-js/oak.html
URL: http://svn.apache.org/viewvc/jackrabbit/site/live/oak/docs/oak-mongo-js/oak.html?rev=1835390&r1=1835389&r2=1835390&view=diff
==============================================================================
--- jackrabbit/site/live/oak/docs/oak-mongo-js/oak.html (original)
+++ jackrabbit/site/live/oak/docs/oak-mongo-js/oak.html Mon Jul  9 08:53:17 2018
@@ -4114,7 +4114,7 @@ is inactive.
 <br class="clear">
 
 <footer>
-    Documentation generated by <a href="https://github.com/jsdoc3/jsdoc">JSDoc 3.3.2</a> on Thu May 24 2018 12:33:47 GMT+0200 (CEST)
+    Documentation generated by <a href="https://github.com/jsdoc3/jsdoc">JSDoc 3.3.2</a> on Mon Jul 09 2018 10:50:53 GMT+0200 (CEST)
 </footer>
 
 <script> prettyPrint(); </script>

Modified: jackrabbit/site/live/oak/docs/oak_api/error_codes.html
URL: http://svn.apache.org/viewvc/jackrabbit/site/live/oak/docs/oak_api/error_codes.html?rev=1835390&r1=1835389&r2=1835390&view=diff
==============================================================================
--- jackrabbit/site/live/oak/docs/oak_api/error_codes.html (original)
+++ jackrabbit/site/live/oak/docs/oak_api/error_codes.html Mon Jul  9 08:53:17 2018
@@ -1,13 +1,13 @@
 <!DOCTYPE html>
 <!--
- | Generated by Apache Maven Doxia Site Renderer 1.7.4 at 2018-05-24 
+ | Generated by Apache Maven Doxia Site Renderer 1.8.1 at 2018-07-09 
  | Rendered using Apache Maven Fluido Skin 1.6
 -->
 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
   <head>
     <meta charset="UTF-8" />
     <meta name="viewport" content="width=device-width, initial-scale=1.0" />
-    <meta name="Date-Revision-yyyymmdd" content="20180524" />
+    <meta name="Date-Revision-yyyymmdd" content="20180709" />
     <meta http-equiv="Content-Language" content="en" />
     <title>Jackrabbit Oak &#x2013; Error Codes</title>
     <link rel="stylesheet" href="../css/apache-maven-fluido-1.6.min.css" />
@@ -136,7 +136,7 @@
 
       <div id="breadcrumbs">
         <ul class="breadcrumb">
-        <li id="publishDate">Last Published: 2018-05-24<span class="divider">|</span>
+        <li id="publishDate">Last Published: 2018-07-09<span class="divider">|</span>
 </li>
           <li id="projectVersion">Version: 1.10-SNAPSHOT</li>
         </ul>
@@ -240,117 +240,66 @@
    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.
-  --><h1>Error Codes</h1>
+  -->
+<h1>Error Codes</h1>
 <p>Since <a class="externalLink" href="https://issues.apache.org/jira/browse/OAK-764">OAK-764</a> the CommitFailedExceptions thrown by commit hooks in Oak come with error codes that help identify the cause of a problem and locate additional information about the issue. This page is an informal registry of common error codes.</p>
 <div class="section">
 <div class="section">
 <h3><a name="Type_Constraint"></a>Type Constraint</h3>
 <div class="section">
 <h4><a name="Node_type_validation"></a>Node type validation</h4>
-
 <table border="0" class="table table-striped">
-  <thead>
-    
+<thead>
+
 <tr class="a">
-      
-<th>OakConstraint000x </th>
-      
-<th>Primary and mixin type information </th>
-    </tr>
-  </thead>
-  <tbody>
-    
+<th> OakConstraint000x </th>
+<th> Primary and mixin type information                       </th></tr>
+</thead><tbody>
+
 <tr class="b">
-      
-<td>0001 </td>
-      
-<td>The primary type X does not exist </td>
-    </tr>
-    
+<td> 0001              </td>
+<td> The primary type X does not exist                        </td></tr>
 <tr class="a">
-      
-<td>0002 </td>
-      
-<td>Mixin type X used as the primary type </td>
-    </tr>
-    
+<td> 0002              </td>
+<td> Mixin type X used as the primary type                    </td></tr>
 <tr class="b">
-      
-<td>0003 </td>
-      
-<td>Abstract type X used as the primary type </td>
-    </tr>
-    
+<td> 0003              </td>
+<td> Abstract type X used as the primary type                 </td></tr>
 <tr class="a">
-      
-<td>0004 </td>
-      
-<td>No default primary type available for child node X </td>
-    </tr>
-    
+<td> 0004              </td>
+<td> No default primary type available for child node X       </td></tr>
 <tr class="b">
-      
-<td>0005 </td>
-      
-<td>The mixin type X does not exist </td>
-    </tr>
-    
+<td> 0005              </td>
+<td> The mixin type X does not exist                          </td></tr>
 <tr class="a">
-      
-<td>0006 </td>
-      
-<td>Primary type X used as a mixin type </td>
-    </tr>
-    
+<td> 0006              </td>
+<td> Primary type X used as a mixin type                      </td></tr>
 <tr class="b">
-      
-<td>0007 </td>
-      
-<td>Abstract type X used as a mixin type </td>
-    </tr>
-  </tbody>
+<td> 0007              </td>
+<td> Abstract type X used as a mixin type                     </td></tr>
+</tbody>
 </table>
-
 <table border="0" class="table table-striped">
-  <thead>
-    
+<thead>
+
 <tr class="a">
-      
-<th>OakConstraint002x </th>
-      
-<th>Presence of mandatory items </th>
-    </tr>
-  </thead>
-  <tbody>
-    
+<th> OakConstraint002x </th>
+<th> Presence of mandatory items                              </th></tr>
+</thead><tbody>
+
 <tr class="b">
-      
-<td>0021 </td>
-      
-<td>Mandatory property X not included in a new node </td>
-    </tr>
-    
+<td> 0021              </td>
+<td> Mandatory property X not included in a new node          </td></tr>
 <tr class="a">
-      
-<td>0022 </td>
-      
-<td>Mandatory property X can not be removed </td>
-    </tr>
-    
+<td> 0022              </td>
+<td> Mandatory property X can not be removed                  </td></tr>
 <tr class="b">
-      
-<td>0025 </td>
-      
-<td>Mandatory child node X not included in a new node </td>
-    </tr>
-    
+<td> 0025              </td>
+<td> Mandatory child node X not included in a new node        </td></tr>
 <tr class="a">
-      
-<td>0026 </td>
-      
-<td>Mandatory child node X can not be removed </td>
-    </tr>
-  </tbody>
+<td> 0026              </td>
+<td> Mandatory child node X can not be removed                </td></tr>
+</tbody>
 </table></div>
 <div class="section">
 <h4><a name="User_Validation"></a>User Validation</h4>
@@ -373,8 +322,7 @@
 <p>see section <a href="../security/accesscontrol/default.html#validation">Access Control Management</a></p></div>
 <div class="section">
 <h4><a name="CUG_Validation"></a>CUG Validation</h4>
-<p>see section <a href="../security/authorization/cug.html#validation">Closed User Groups</a></p>
-<!-- hidden references --></div></div></div>
+<p>see section <a href="../security/authorization/cug.html#validation">Closed User Groups</a></p><!-- hidden references --></div></div></div>
         </div>
       </div>
     </div>

Modified: jackrabbit/site/live/oak/docs/oak_api/overview.html
URL: http://svn.apache.org/viewvc/jackrabbit/site/live/oak/docs/oak_api/overview.html?rev=1835390&r1=1835389&r2=1835390&view=diff
==============================================================================
--- jackrabbit/site/live/oak/docs/oak_api/overview.html (original)
+++ jackrabbit/site/live/oak/docs/oak_api/overview.html Mon Jul  9 08:53:17 2018
@@ -1,13 +1,13 @@
 <!DOCTYPE html>
 <!--
- | Generated by Apache Maven Doxia Site Renderer 1.7.4 at 2018-05-24 
+ | Generated by Apache Maven Doxia Site Renderer 1.8.1 at 2018-07-09 
  | Rendered using Apache Maven Fluido Skin 1.6
 -->
 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
   <head>
     <meta charset="UTF-8" />
     <meta name="viewport" content="width=device-width, initial-scale=1.0" />
-    <meta name="Date-Revision-yyyymmdd" content="20180524" />
+    <meta name="Date-Revision-yyyymmdd" content="20180709" />
     <meta http-equiv="Content-Language" content="en" />
     <title>Jackrabbit Oak &#x2013; Oak API</title>
     <link rel="stylesheet" href="../css/apache-maven-fluido-1.6.min.css" />
@@ -136,7 +136,7 @@
 
       <div id="breadcrumbs">
         <ul class="breadcrumb">
-        <li id="publishDate">Last Published: 2018-05-24<span class="divider">|</span>
+        <li id="publishDate">Last Published: 2018-07-09<span class="divider">|</span>
 </li>
           <li id="projectVersion">Version: 1.10-SNAPSHOT</li>
         </ul>
@@ -241,99 +241,68 @@
    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.
-  --><div class="section">
+  -->
+<div class="section">
 <h2><a name="Oak_API"></a>Oak API</h2>
-
 <ul>
-  
+
 <li><a href="../apidocs/">Javadocs</a> (latest release)</li>
-  
 <li>Javadoc of previous releases are available from <a class="externalLink" href="http://www.javadoc.io/">javadoc.io</a>:
-  
 <ul>
-    
+
 <li><a class="externalLink" href="http://www.javadoc.io/doc/org.apache.jackrabbit/oak-jcr/">oak-jcr</a></li>
-    
 <li><a class="externalLink" href="http://www.javadoc.io/doc/org.apache.jackrabbit/oak-core/">oak-core</a></li>
-    
 <li><a class="externalLink" href="http://www.javadoc.io/doc/org.apache.jackrabbit/oak-run/">oak-run</a></li>
-    
 <li><a class="externalLink" href="http://www.javadoc.io/doc/org.apache.jackrabbit/oak-upgrade/">oak-upgrade</a></li>
-    
 <li><a class="externalLink" href="http://www.javadoc.io/doc/org.apache.jackrabbit/oak-commons/">oak-commons</a></li>
-    
 <li><a class="externalLink" href="http://www.javadoc.io/doc/org.apache.jackrabbit/oak-blob/">oak-blob</a></li>
-    
 <li><a class="externalLink" href="http://www.javadoc.io/doc/org.apache.jackrabbit/oak-blob-cloud/">oak-blob-cloud</a></li>
-    
 <li><a class="externalLink" href="http://www.javadoc.io/doc/org.apache.jackrabbit/oak-http/">oak-http</a></li>
-    
 <li><a class="externalLink" href="http://www.javadoc.io/doc/org.apache.jackrabbit/oak-lucene/">oak-lucene</a></li>
-    
 <li><a class="externalLink" href="http://www.javadoc.io/doc/org.apache.jackrabbit/oak-solr-core/">oak-solr-core</a></li>
-    
 <li><a class="externalLink" href="http://www.javadoc.io/doc/org.apache.jackrabbit/oak-solr-osgi/">oak-solr-osgi</a></li>
-    
 <li><a class="externalLink" href="http://www.javadoc.io/doc/org.apache.jackrabbit/oak-auth-external/">oak-auth-external</a></li>
-    
 <li><a class="externalLink" href="http://www.javadoc.io/doc/org.apache.jackrabbit/oak-auth-ldap/">oak-auth-ldap</a></li>
-    
 <li><a class="externalLink" href="http://www.javadoc.io/doc/org.apache.jackrabbit/oak-segment-tar/">oak-segment-tar</a></li>
-    
 <li><a class="externalLink" href="http://www.javadoc.io/doc/org.apache.jackrabbit/oak-authorization-cug/">oak-authorization-cug</a></li>
-    
 <li><a class="externalLink" href="http://www.javadoc.io/doc/org.apache.jackrabbit/oak-exercise/">oak-exercise</a></li>
-  </ul></li>
+</ul>
+</li>
 </ul>
 <div class="section">
 <h3><a name="Key_API_entry_points"></a>Key API entry points</h3>
-
 <ul>
-  
+
 <li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/api/ContentRepository.html">ContentRepository</a></li>
-  
 <li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/api/ContentSession.html">ContentSession</a></li>
-  
 <li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/api/Root.html">Root</a></li>
-  
 <li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/api/Tree.html">Tree</a></li>
-  
 <li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/api/PropertyState.html">PropertyState</a></li>
 </ul>
 <div class="section">
 <h4><a name="Values"></a>Values</h4>
-
 <ul>
-  
+
 <li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/api/PropertyValue.html">PropertyValue</a></li>
-  
 <li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/api/Type.html">Type</a></li>
-  
 <li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/api/Blob.html">Blob</a></li>
 </ul></div>
 <div class="section">
 <h4><a name="Query"></a>Query</h4>
-
 <ul>
-  
+
 <li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/api/QueryEngine.html">QueryEngine</a></li>
-  
 <li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/api/Query.html">Query</a></li>
-  
 <li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/api/ResultRow.html">ResultRow</a></li>
 </ul></div>
 <div class="section">
 <h4><a name="Various"></a>Various</h4>
-
 <ul>
-  
+
 <li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/api/AuthInfo.html">AuthInfo</a> : see section <a href="../security/authentication.html">Authentication</a></li>
-  
 <li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/api/Descriptors.html">Descriptors</a></li>
-  
 <li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/api/CommitFailedException.html">CommitFailedException</a> : see also <a href="error_codes.html">Error Codes</a></li>
-</ul>
-<!-- hidden references --></div></div></div>
+</ul><!-- hidden references --></div></div></div>
         </div>
       </div>
     </div>

Modified: jackrabbit/site/live/oak/docs/osgi_config.html
URL: http://svn.apache.org/viewvc/jackrabbit/site/live/oak/docs/osgi_config.html?rev=1835390&r1=1835389&r2=1835390&view=diff
==============================================================================
--- jackrabbit/site/live/oak/docs/osgi_config.html (original)
+++ jackrabbit/site/live/oak/docs/osgi_config.html Mon Jul  9 08:53:17 2018
@@ -1,13 +1,13 @@
 <!DOCTYPE html>
 <!--
- | Generated by Apache Maven Doxia Site Renderer 1.7.4 at 2018-05-24 
+ | Generated by Apache Maven Doxia Site Renderer 1.8.1 at 2018-07-09 
  | Rendered using Apache Maven Fluido Skin 1.6
 -->
 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
   <head>
     <meta charset="UTF-8" />
     <meta name="viewport" content="width=device-width, initial-scale=1.0" />
-    <meta name="Date-Revision-yyyymmdd" content="20180524" />
+    <meta name="Date-Revision-yyyymmdd" content="20180709" />
     <meta http-equiv="Content-Language" content="en" />
     <title>Jackrabbit Oak &#x2013; Repository OSGi Configuration</title>
     <link rel="stylesheet" href="./css/apache-maven-fluido-1.6.min.css" />
@@ -136,7 +136,7 @@
 
       <div id="breadcrumbs">
         <ul class="breadcrumb">
-        <li id="publishDate">Last Published: 2018-05-24<span class="divider">|</span>
+        <li id="publishDate">Last Published: 2018-07-09<span class="divider">|</span>
 </li>
           <li id="projectVersion">Version: 1.10-SNAPSHOT</li>
         </ul>
@@ -241,15 +241,16 @@
    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.
-  --><h1>Repository OSGi Configuration</h1>
+  -->
+<h1>Repository OSGi Configuration</h1>
 <p>Oak comes with a simple mechanism for constructing content repositories for use in embedded deployments and test cases. Details regarding that are provided as part of <a href="construct.html">Repository Construction</a>. When used in OSGi environment then various Oak components can be configured using OSGi Configuration Support.</p>
 <p>Depending on component the configuration can be modified at runtime or needs to be specified before the initial system setup.</p>
-
 <dl>
+
 <dt>Static Configuration</dt>
-<dd>Such configuration settings cannot be changed once a repository  is initialized. For example choosing a <tt>DataStore</tt> or specifying the path of User Home.  Such properties should not be changed once a system is initialized.</dd>
+<dd>Such configuration settings cannot be changed once a repository is initialized. For example choosing a <tt>DataStore</tt> or specifying the path of User Home. Such properties should not be changed once a system is initialized.</dd>
 <dt>Dynamic Configuration</dt>
-<dd>Some of the configuration settings like thread pool size, cache size etc can be changed  at runtime or after initial system setup</dd>
+<dd>Some of the configuration settings like thread pool size, cache size etc can be changed at runtime or after initial system setup</dd>
 </dl>
 <p>Each OSGi configuration is referred via a PID i.e. persistent identifier. Sections below provide details around various PID used in Oak</p>
 <div class="section">
@@ -262,8 +263,8 @@
 <p>The second and last configuration, identified by <tt>org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService</tt>, refers to the old implementation of the Node Store provided by the <tt>oak-segment</tt> bundle. This implementation has been deprecated and removed in Oak 1.8. It will not receive any further improvements and should not be used in new projects.</p>
 <div class="section">
 <h5><a name="org.apache.jackrabbit.oak.segment.SegmentNodeStoreService"></a><a name="config-SegmentNodeStoreService"></a> org.apache.jackrabbit.oak.segment.SegmentNodeStoreService</h5>
-
 <dl>
+
 <dt>repository.home (string) - repository</dt>
 <dd>A path on the file system where repository data will be stored. The Segment Store persists its data in a subdirectory of <tt>repository.home</tt> named <tt>segmentstore</tt>. The provided path can be relative or absolute. If a relative path is provided, it is handled according to the definition of relative path as specified by <tt>java.io.File</tt>. Placeholders of any kind in the path are not supported.</dd>
 <dt>tarmk.mode (string) - 64</dt>
@@ -308,8 +309,8 @@
 <div class="section">
 <h5><a name="org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService"></a>org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService</h5>
 <p><b>This configuration is deprecated and has been removed in Oak 1.8. It belongs to the legacy Node Store implementation provided by the oak-segment bundle. This implementation should not be used anymore. Instead, rely on the Node Store implementation provided by the oak-segment-tar bundle, whose configuration is described above.</b></p>
-
 <dl>
+
 <dt>repository.home (string) - tarmk</dt>
 <dd>A path on the file system where repository data will be stored. The Segment Store persists its data in a subdirectory of <tt>repository.home</tt> named <tt>segmentstore</tt>. The provided path can be relative or absolute. If a relative path is provided, it is handled according to the definition of relative path as specified by <tt>java.io.File</tt>. Placeholders of any kind in the path are not supported.</dd>
 <dt>tarmk.mode (string) - 64</dt>
@@ -345,7 +346,7 @@
 <dt>customBlobStore (boolean) - false</dt>
 <dd>Determines if this Node Store is supposed to use a custom Blob Store. If this property is <tt>true</tt>, a Data Store or a Blob Store needs to be configured for the Segment Store to pick it up (see below). If this property is <tt>false</tt>, binaries will be stored in the Segment Store.</dd>
 <dt>blobGcMaxAgeInSecs (long) - 86400</dt>
-<dd>BLOB Garbage Collector (GC) logic would only consider those BLOBs for GC which are not accessed recently (currentTime - lastModifiedTime &gt; blobGcMaxAgeInSecs). For example, as per default, only those BLOBs which have been created 24 hours in the past would be considered for GC.  It is strongly advised to not set this property to a very low value of say a few minutes but only set it to a hour at a  minimum. This is to ensure that the NodeStore(s) have had the time to flush out its internal data structures to  persistence and the references to recently added blobs are accounted.</dd>
+<dd>BLOB Garbage Collector (GC) logic would only consider those BLOBs for GC which are not accessed recently (currentTime - lastModifiedTime &gt; blobGcMaxAgeInSecs). For example, as per default, only those BLOBs which have been created 24 hours in the past would be considered for GC. It is strongly advised to not set this property to a very low value of say a few minutes but only set it to a hour at a minimum. This is to ensure that the NodeStore(s) have had the time to flush out its internal data structures to persistence and the references to recently added blobs are accounted.</dd>
 <dt>blobTrackSnapshotIntervalInSecs (long) - 43200</dt>
 <dd>The blob ids cached/tracked locally are synchronized with the DataStore at this interval. Any additions and deletions will be visible to other cluster nodes or repositories connected to the shared DatStore after this. This should be less than the blobGcMaxAgeInSecs parameter above and the frequency of blob gc. See <a href="./plugins/blobstore.html#blobid-tracker">Blob tracker</a>.</dd>
 </dl>
@@ -353,8 +354,8 @@
 <div class="section">
 <h4><a name="DocumentNodeStore"></a>DocumentNodeStore</h4>
 <p><i>PID <tt>org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService</tt></i></p>
-
 <dl>
+
 <dt>mongouri</dt>
 <dd>Default - <a class="externalLink" href="mongodb://localhost:27017">mongodb://localhost:27017</a></dd>
 <dd>Specifies the <a class="externalLink" href="http://docs.mongodb.org/manual/reference/connection-string/">MongoURI</a> required to connect to Mongo Database</dd>
@@ -376,32 +377,32 @@
 <dd>Boolean value indicating that custom <tt>BlobStore</tt> to use. By default it uses <tt>MongoBlobStore</tt>.</dd>
 <dt>maxReplicationLagInSecs</dt>
 <dd>Default 21600 (6 hours)</dd>
-<dd>Determines the duration beyond which it can be safely assumed that state on secondary would be consistent  with primary and its safe to read from them. (See <a class="externalLink" href="https://issues.apache.org/jira/browse/OAK-1645">OAK-1645</a>)</dd>
+<dd>Determines the duration beyond which it can be safely assumed that state on secondary would be consistent with primary and its safe to read from them. (See <a class="externalLink" href="https://issues.apache.org/jira/browse/OAK-1645">OAK-1645</a>)</dd>
 <dt>blobGcMaxAgeInSecs</dt>
 <dd>Default 86400 (24 hrs)</dd>
-<dd>Blob Garbage Collector (GC) logic would only consider those blobs for GC which are not accessed recently  (currentTime - lastModifiedTime &gt; blobGcMaxAgeInSecs). For example as per default only those blobs which have  been created 24 hrs ago would be considered for GC. It is strongly advised to not set this property to a very low  value of say a few minutes but only set it to a hour at a minimum. This is to ensure that the NodeStore(s) have had the  time to flush out its internal data structures to persistence and the references to recently added blobs are  accounted.</dd>
+<dd>Blob Garbage Collector (GC) logic would only consider those blobs for GC which are not accessed recently (currentTime - lastModifiedTime &gt; blobGcMaxAgeInSecs). For example as per default only those blobs which have been created 24 hrs ago would be considered for GC. It is strongly advised to not set this property to a very low value of say a few minutes but only set it to a hour at a minimum. This is to ensure that the NodeStore(s) have had the time to flush out its internal data structures to persistence and the references to recently added blobs are accounted.</dd>
 <dt>versionGcMaxAgeInSecs</dt>
 <dd>Default 86400 (24 hrs)</dd>
-<dd>Oak uses MVCC model to store the data. So each update to a node results in new version getting created. This  duration controls how much old revision data should be kept. For example if a node is deleted at time T1 then its  content would only be marked deleted at revision for T1 but its content would not be removed. Only when a Revision  GC is run then its content would removed and that too only after (currentTime -T1 &gt; versionGcMaxAgeInSecs)</dd>
+<dd>Oak uses MVCC model to store the data. So each update to a node results in new version getting created. This duration controls how much old revision data should be kept. For example if a node is deleted at time T1 then its content would only be marked deleted at revision for T1 but its content would not be removed. Only when a Revision GC is run then its content would removed and that too only after (currentTime -T1 &gt; versionGcMaxAgeInSecs)</dd>
 <dt>versionGCExpression</dt>
 <dd>Default &quot;&quot;</dd>
-<dd>A cron expression that defines when the Revision GC is scheduled. If this  configuration entry is left empty, the default behaviour depends on the  <tt>documentStoreType</tt>. For <tt>MONGO</tt> the default is to schedule a run every five  seconds (also known as Continuous Revision Garbage Collection). For <tt>RDB</tt> the  default is no scheduled GC. It must be enabled explicitly with a cron  expression. E.g. the following expression triggers a GC run every night at  2 AM: <tt>0 0 2 * * ?</tt>.</dd>
+<dd>A cron expression that defines when the Revision GC is scheduled. If this configuration entry is left empty, the default behaviour depends on the <tt>documentStoreType</tt>. For <tt>MONGO</tt> the default is to schedule a run every five seconds (also known as Continuous Revision Garbage Collection). For <tt>RDB</tt> the default is no scheduled GC. It must be enabled explicitly with a cron expression. E.g. the following expression triggers a GC run every night at 2 AM: <tt>0 0 2 * * ?</tt>.</dd>
 <dd>Since 1.7.11</dd>
 <dt>versionGCTimeLimitInSecs</dt>
 <dd>Default 10800</dd>
-<dd>A Revision GC run is canceled after this number of seconds. The default is  three hours.</dd>
+<dd>A Revision GC run is canceled after this number of seconds. The default is three hours.</dd>
 <dd>Since 1.7.11</dd>
 <dt>journalGCMaxAge</dt>
 <dd>Default 86400000 (24 hrs, was 6 hrs until 1.7.4)</dd>
-<dd>Journal entries older than <tt>journalGCMaxAge</tt> can be removed by the journal  garbage collector. The maximum age is specified in milliseconds.</dd>
+<dd>Journal entries older than <tt>journalGCMaxAge</tt> can be removed by the journal garbage collector. The maximum age is specified in milliseconds.</dd>
 <dd>Since 1.0.19, 1.2.3, 1.4</dd>
 <dt>journalGCInterval</dt>
 <dd>Default 300000 (5 min)</dd>
-<dd>The interval in milliseconds with which the journal garbage collector removes  old journal entries.</dd>
+<dd>The interval in milliseconds with which the journal garbage collector removes old journal entries.</dd>
 <dd>Since 1.0.19, 1.2.3, 1.4</dd>
 <dt>blobCacheSize</dt>
 <dd>Default 16 (MB)</dd>
-<dd>DocumentNodeStore when running with Mongo would use <tt>MongoBlobStore</tt> by default unless a custom <tt>BlobStore</tt> is  configured. In such scenario the size of in memory cache for the frequently used blobs can be configured via  <tt>blobCacheSize</tt>.</dd>
+<dd>DocumentNodeStore when running with Mongo would use <tt>MongoBlobStore</tt> by default unless a custom <tt>BlobStore</tt> is configured. In such scenario the size of in memory cache for the frequently used blobs can be configured via <tt>blobCacheSize</tt>.</dd>
 <dt>persistentCache</dt>
 <dd>Default &#x201c;cache,binary=0&#x201d; (prior to 1.6, the persistent cache was disabled by default)</dd>
 <dd>The <a href="./nodestore/persistent-cache.html">persistent cache</a>, which is stored in the local file system.</dd>
@@ -440,40 +441,44 @@
 </dl>
 <p>Example config file</p>
 
-<div class="source">
-<div class="source"><pre class="prettyprint">mongouri=mongodb://localhost:27017
+<div>
+<div>
+<pre class="source">mongouri=mongodb://localhost:27017
 db=oak
 </pre></div></div>
+
 <div class="section">
 <h5><a name="Mongo_Configuration"></a>Mongo Configuration</h5>
 <p>All the configuration related to Mongo can be specified via <a class="externalLink" href="http://docs.mongodb.org/manual/reference/connection-string/">Mongo URI</a></p>
-
 <ul>
-  
+
 <li>
-<p><b>Authentication</b> - Username and password should be specified as part of uri e.g. the following  connects and logs in to the admin database as user sysop with the password moon:</p>
-  
-<div class="source">
-<div class="source"><pre class="prettyprint">mongodb://sysop:moon@localhost
-</pre></div></div></li>
-  
+
+<p><b>Authentication</b> - Username and password should be specified as part of uri e.g. the following connects and logs in to the admin database as user sysop with the password moon:</p>
+
+<div>
+<div>
+<pre class="source">mongodb://sysop:moon@localhost
+</pre></div></div>
+</li>
 <li>
-<p><b>Read Preferences and Write Concern</b> - These also can be spcified as part of Mongo URI. Refer to  <a href="./nodestore/documentmk.html#rw-preference">Read Preference and Write Concern</a> section for more details. For  e.g. following would set <i>readPreference</i> to <i>secondary</i> and prefer replica with tag <i>dc:ny,rack:1</i>.  It would also specify the write timeout to 10 sec</p>
-  
-<div class="source">
-<div class="source"><pre class="prettyprint">mongodb://db1.example.net,db2.example.com?readPreference=secondary&amp;readPreferenceTags=dc:ny,rack:1&amp;readPreferenceTags=dc:ny&amp;readPreferenceTags=&amp;w=1&amp;wtimeoutMS=10000    
-</pre></div></div></li>
+
+<p><b>Read Preferences and Write Concern</b> - These also can be spcified as part of Mongo URI. Refer to <a href="./nodestore/documentmk.html#rw-preference">Read Preference and Write Concern</a> section for more details. For e.g. following would set <i>readPreference</i> to <i>secondary</i> and prefer replica with tag <i>dc:ny,rack:1</i>. It would also specify the write timeout to 10 sec</p>
+
+<div>
+<div>
+<pre class="source">mongodb://db1.example.net,db2.example.com?readPreference=secondary&amp;readPreferenceTags=dc:ny,rack:1&amp;readPreferenceTags=dc:ny&amp;readPreferenceTags=&amp;w=1&amp;wtimeoutMS=10000    
+</pre></div></div>
+</li>
 </ul>
-<p>One can also specify the connection pool size, socket timeout etc. For complete details about various possible option refer to <a class="externalLink" href="http://docs.mongodb.org/manual/reference/connection-string/">Mongo URI</a> </p>
-<p><a name="config-blobstore"></a> </p></div></div></div>
+<p>One can also specify the connection pool size, socket timeout etc. For complete details about various possible option refer to <a class="externalLink" href="http://docs.mongodb.org/manual/reference/connection-string/">Mongo URI</a></p>
+<p><a name="config-blobstore"></a></p></div></div></div>
 <div class="section">
 <h3><a name="Configuring_DataStoreBlobStore"></a>Configuring DataStore/BlobStore</h3>
 <p>BlobStores are used to store the binary content. Support for Jackrabbit 2 <tt>DataStore</tt> is also provided via a <tt>DataStoreBlobStore</tt> wrapper. To use a specific BlobStore implementation following two steps need to be performed</p>
-
 <ol style="list-style-type: decimal">
-  
+
 <li>Configure NodeStore - NodeStore config need to be modified to enable use of custom BlobStore via setting <tt>customBlobStore</tt> to true</li>
-  
 <li>Configure BlobStore - Create config for the required BlobStore by using the PID for that BlobStore.</li>
 </ol>
 <p>Refer to <a href="#config-sling">Config steps in Apache Sling</a> for an example on how to configure a <tt>FileDataStore</tt> with <tt>DocumentNodeStore</tt></p>
@@ -481,8 +486,8 @@ db=oak
 <h4><a name="Jackrabbit_2_-_FileDataStore"></a>Jackrabbit 2 - FileDataStore</h4>
 <p>Jackrabbit 2 <a class="externalLink" href="http://jackrabbit.apache.org/api/2.4/org/apache/jackrabbit/core/data/FileDataStore.html">FileDataStore</a> can be configured via following <i>pid</i></p>
 <p><i>PID <tt>org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore</tt></i></p>
-
 <dl>
+
 <dt>path</dt>
 <dd>Default - Not specified</dd>
 <dd>Path to the directory under which the files would be stored.</dd>
@@ -494,10 +499,10 @@ db=oak
 <dd>Size in bytes. Binaries with size less than or equal to this size would be stored in in memory cache</dd>
 <dt>cacheSizeInMB</dt>
 <dd>Default - 16</dd>
-<dd>Size in MB. In memory cache for storing small files whose size is less than <tt>maxCachedBinarySize</tt>. This  helps in better performance when lots of small binaries are accessed frequently.</dd>
+<dd>Size in MB. In memory cache for storing small files whose size is less than <tt>maxCachedBinarySize</tt>. This helps in better performance when lots of small binaries are accessed frequently.</dd>
 <dt>cacheSize</dt>
 <dd>Default - 0</dd>
-<dd>Size in bytes of FileDataStore cache. Cache is enabled when cacheSize &gt; 0. Default is disabled.</dd>
+<dd>Size in bytes of FileDataStore cache. Cache is enabled when cacheSize &gt; 0.  Default is disabled.</dd>
 <dt>cachePath</dt>
 <dd>Default - ${home.dir}/repository/datastore</dd>
 <dd>Path of local file system cache</dd>
@@ -505,50 +510,46 @@ db=oak
 <div class="section">
 <h4><a name="Jackrabbit_2_-_S3DataStore"></a>Jackrabbit 2 - S3DataStore</h4>
 <p><i>PID <tt>org.apache.jackrabbit.oak.plugins.blob.datastore.S3DataStore</tt></i></p>
-
 <dl>
+
 <dt>maxCachedBinarySize</dt>
 <dd>Default - 17408 (17 KB)</dd>
 <dd>Size in bytes. Binaries with size less than or equal to this size would be stored in in memory cache</dd>
 <dt>cacheSizeInMB</dt>
 <dd>Default - 16</dd>
-<dd>Size in MB. In memory cache for storing small files whose size is less than <tt>maxCachedBinarySize</tt>. This  helps in better performance when lots of small binaries are accessed frequently.</dd>
+<dd>Size in MB. In memory cache for storing small files whose size is less than <tt>maxCachedBinarySize</tt>. This helps in better performance when lots of small binaries are accessed frequently.</dd>
 </dl></div>
 <div class="section">
 <h4><a name="Oak_-_SharedS3DataStore_Since_Oak_1.2.0"></a>Oak - SharedS3DataStore (Since Oak 1.2.0)</h4>
 <p>Supports shared S3 DataStore</p>
 <p><i>PID <tt>org.apache.jackrabbit.oak.plugins.blob.datastore.SharedS3DataStore</tt></i></p>
-
 <dl>
+
 <dt>maxCachedBinarySize</dt>
 <dd>Default - 17408 (17 KB)</dd>
 <dd>Size in bytes. Binaries with size less than or equal to this size would be stored in in memory cache</dd>
 <dt>cacheSizeInMB</dt>
 <dd>Default - 16</dd>
-<dd>Size in MB. In memory cache for storing small files whose size is less than <tt>maxCachedBinarySize</tt>. This  helps in better performance when lots of small binaries are accessed frequently.</dd>
+<dd>Size in MB. In memory cache for storing small files whose size is less than <tt>maxCachedBinarySize</tt>. This helps in better performance when lots of small binaries are accessed frequently.</dd>
 </dl></div>
 <div class="section">
 <h4><a name="Oak_-_AbstractSharedCachingDataStore_OAK_1.6.x"></a>Oak - AbstractSharedCachingDataStore (OAK 1.6.x)</h4>
 <p>All the above data stores enable local file system caching with the following parameters</p>
-
 <ul>
-  
+
 <li><i>PID <tt>org.apache.jackrabbit.oak.plugins.blob.datastore.SharedS3DataStore</tt></i></li>
-  
 <li><i>PID <tt>org.apache.jackrabbit.oak.plugins.blob.datastore.S3DataStore</tt></i></li>
-  
 <li><i>PID <tt>org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore</tt></i></li>
-  
 <li><i>PID <tt>org.apache.jackrabbit.oak.plugins.blob.datastore.AzureDataStore</tt></i></li>
 </ul>
-
 <dl>
+
 <dt>cacheSize</dt>
 <dd>Default - 68719476736</dd>
 <dd>Size in bytes of DataStore cache. Cache is disabled when cacheSize &lt;= 0.</dd>
 <dt>stagingSplitPercentage</dt>
 <dd>Default - 10</dd>
-<dd>Percentage of cache earmarked for asynchronous upload staging. The rest would be used for caching the downloaded  files.</dd>
+<dd>Percentage of cache earmarked for asynchronous upload staging. The rest would be used for caching the downloaded files.</dd>
 <dt>uploadThreads</dt>
 <dd>Default - 10</dd>
 <dd>The number of background threads used for asynchronous uploads.</dd>
@@ -564,8 +565,8 @@ db=oak
 <p>Following properties are supported by Oak. They are grouped in two parts <i>Stable</i> and <i>Experimental</i>. The stable properties would be supported in future version but the experimental properties would <i>might</i> not be supported in future versions</p>
 <div class="section">
 <h4><a name="Stable"></a>Stable</h4>
-
 <dl>
+
 <dt>oak.mongo.uri</dt>
 <dd>Type - System property and Framework Property</dd>
 <dd>Specifies the <a class="externalLink" href="http://docs.mongodb.org/manual/reference/connection-string/">MongoURI</a> required to connect to Mongo Database</dd>
@@ -579,14 +580,13 @@ db=oak
 <h3><a name="Configuration_Steps_for_Apache_Sling"></a>Configuration Steps for Apache Sling</h3>
 <p>The OSGi Configuration Admin service defines a mechanism for passing configuration settings to an OSGi bundle. How a configuration is registered with the OSGi system varies depending on the application.</p>
 <p><a name="config-sling"></a> For example to configure <tt>DocumentNodeStore</tt> to use <tt>FileDataStore</tt> in Apache Sling</p>
-
 <ol style="list-style-type: decimal">
-  
-<li>
-<p>Create a config file with name <i>org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.cfg</i> under <i>${sling.home}/install</i> folder with content</p>
-  
-<div class="source">
-<div class="source"><pre class="prettyprint">#Mongo server details
+
+<li>Create a config file with name <i>org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.cfg</i> under <i>${sling.home}/install</i> folder with content
+
+<div>
+<div>
+<pre class="source">#Mongo server details
 mongouri=mongodb://localhost:27017
 
 #Name of Mongo database to use
@@ -594,13 +594,13 @@ db=aem-author
 
 #Store binaries in custom BlobStore e.g. FileDataStore
 customBlobStore=true
-</pre></div></div></li>
-  
-<li>
-<p>Create a config file with name <i>org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.cfg</i> under  <i>${sling.home}/install</i> folder with content</p>
-  
-<div class="source">
-<div class="source"><pre class="prettyprint">#The minimum size of an object that should be stored in this data store.
+</pre></div></div>
+</li>
+<li>Create a config file with name <i>org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.cfg</i> under <i>${sling.home}/install</i> folder with content
+
+<div>
+<div>
+<pre class="source">#The minimum size of an object that should be stored in this data store.
 minRecordLength=4096
 
 #path to the DataStore
@@ -608,17 +608,16 @@ path=./sling/repository/datastore
 
 #cache for storing small binaries in-memory
 cacheSizeInMB=128
-</pre></div></div></li>
+</pre></div></div>
+</li>
 </ol>
 <div class="section">
 <h4><a name="Framework_Properties_vs_OSGi_Configuration"></a>Framework Properties vs OSGi Configuration</h4>
 <p>OSGi components can read config data from two sources.</p>
-
 <ol style="list-style-type: decimal">
-  
-<li>ConfigurationAdmin - These are configured via placing the *.cfg files under <i>${sling.home}/install</i> folder.  These can also be modified at runtime via Felix WebConsole typically available at <a class="externalLink" href="http://localhost:8080/system/console">http://localhost:8080/system/console</a></li>
-  
-<li>Framework Properties - An OSGi framework can be configured to start with some framework properties. These  properties cannot be changed at runtime. In Apache Sling these can be specified in <i>${sling.home}/sling.properties</i>  or <i>${sling.home}/conf/sling.properties</i></li>
+
+<li>ConfigurationAdmin - These are configured via placing the *.cfg files under <i>${sling.home}/install</i> folder. These can also be modified at runtime via Felix WebConsole typically available at <a class="externalLink" href="http://localhost:8080/system/console">http://localhost:8080/system/console</a></li>
+<li>Framework Properties - An OSGi framework can be configured to start with some framework properties. These properties cannot be changed at runtime. In Apache Sling these can be specified in <i>${sling.home}/sling.properties</i> or <i>${sling.home}/conf/sling.properties</i></li>
 </ol>
 <p>In Oak some of the config properties are also read from <i>framework properties</i>. If a value is specified in both config file and framework properties then framework property takes precedence.</p>
 <p>For example by default Sling sets <b>repository.home</b> to <i>${sling.home}/repository</i>. So this value need not be specified in config files</p></div></div></div>

Modified: jackrabbit/site/live/oak/docs/participating.html
URL: http://svn.apache.org/viewvc/jackrabbit/site/live/oak/docs/participating.html?rev=1835390&r1=1835389&r2=1835390&view=diff
==============================================================================
--- jackrabbit/site/live/oak/docs/participating.html (original)
+++ jackrabbit/site/live/oak/docs/participating.html Mon Jul  9 08:53:17 2018
@@ -1,13 +1,13 @@
 <!DOCTYPE html>
 <!--
- | Generated by Apache Maven Doxia Site Renderer 1.7.4 at 2018-05-24 
+ | Generated by Apache Maven Doxia Site Renderer 1.8.1 at 2018-07-09 
  | Rendered using Apache Maven Fluido Skin 1.6
 -->
 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
   <head>
     <meta charset="UTF-8" />
     <meta name="viewport" content="width=device-width, initial-scale=1.0" />
-    <meta name="Date-Revision-yyyymmdd" content="20180524" />
+    <meta name="Date-Revision-yyyymmdd" content="20180709" />
     <meta http-equiv="Content-Language" content="en" />
     <title>Jackrabbit Oak &#x2013; Participating</title>
     <link rel="stylesheet" href="./css/apache-maven-fluido-1.6.min.css" />
@@ -136,7 +136,7 @@
 
       <div id="breadcrumbs">
         <ul class="breadcrumb">
-        <li id="publishDate">Last Published: 2018-05-24<span class="divider">|</span>
+        <li id="publishDate">Last Published: 2018-07-09<span class="divider">|</span>
 </li>
           <li id="projectVersion">Version: 1.10-SNAPSHOT</li>
         </ul>
@@ -241,11 +241,12 @@
    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.
-  --><div class="section">
+  -->
+<div class="section">
 <h2><a name="Participating"></a>Participating</h2>
-<p>The best place for Oak-related discussions is the <a class="externalLink" href="mailto:oak-dev@jackrabbit.apache.org">oak-dev@</a> mailing list. To subscribe, send a message to <a class="externalLink" href="mailto:oak-dev-subscribe@jackrabbit.apache.org">oak-dev-subscribe@</a>. </p>
-<p>Use the <a class="externalLink" href="https://issues.apache.org/jira/browse/OAK">OAK issue tracker</a> to submit issues, comments or patches. To subscribe to issue notifications, send a message to <a class="externalLink" href="mailto:oak-issues-subscribe@jackrabbit.apache.org">oak-issues@</a>. </p>
-<p>The latest Oak sources are available for checkout from <a class="externalLink" href="https://svn.apache.org/repos/asf/jackrabbit/oak/trunk">svn</a> and can also be browsed using the <a class="externalLink" href="http://svn.apache.org/viewvc/jackrabbit/oak/trunk/">ViewVC</a> interface. You can also <a class="externalLink" href="https://github.com/apache/jackrabbit-oak">fork them</a> on GitHub. To subscribe to commit notifications, send a message to <a class="externalLink" href="mailto:oak-commits-subscribe@jackrabbit.apache.org">oak-commits@</a>.</p>
+<p>The best place for Oak-related discussions is the <a class="externalLink" href="mailto:oak-dev@jackrabbit.apache.org">oak-dev@</a> mailing list. To subscribe, send a message to [oak-dev-subscribe@] (mailto:<a class="externalLink" href="mailto:oak-dev-subscribe@jackrabbit.apache.org">oak-dev-subscribe@jackrabbit.apache.org</a>).</p>
+<p>Use the <a class="externalLink" href="https://issues.apache.org/jira/browse/OAK">OAK issue tracker</a> to submit issues, comments or patches. To subscribe to issue notifications, send a message to [oak-issues@] (mailto:<a class="externalLink" href="mailto:oak-issues-subscribe@jackrabbit.apache.org">oak-issues-subscribe@jackrabbit.apache.org</a>).</p>
+<p>The latest Oak sources are available for checkout from <a class="externalLink" href="https://svn.apache.org/repos/asf/jackrabbit/oak/trunk">svn</a> and can also be browsed using the <a class="externalLink" href="http://svn.apache.org/viewvc/jackrabbit/oak/trunk/">ViewVC</a> interface. You can also <a class="externalLink" href="https://github.com/apache/jackrabbit-oak">fork them</a> on GitHub. To subscribe to commit notifications, send a message to [oak-commits@] (mailto:<a class="externalLink" href="mailto:oak-commits-subscribe@jackrabbit.apache.org">oak-commits-subscribe@jackrabbit.apache.org</a>).</p>
 <p>For more details related to various mailing list have a look at <a class="externalLink" href="http://jackrabbit.apache.org/mailing-lists.html">http://jackrabbit.apache.org/mailing-lists.html</a></p>
 <p>We generally follow a <a class="externalLink" href="https://www.apache.org/foundation/glossary.html#CommitThenReview">CTR</a> policy. However it is up to each individual committer to pro-actively ask for a review of a patch on oak-dev@ or to even call for a <a class="externalLink" href="https://www.apache.org/foundation/glossary.html#ReviewThenCommit">RTC</a>. Special care should be taken with backports to maintenance branches. Back ports bear a certain risk of introducing regressions to otherwise stable branches. Each back ported change should be carefully evaluated for its potential impact, risk and possible mitigation. It is the responsibility of each committer to asses these and ask for advise or reviewing on oak-dev@ if uncertain. Whether using RTC or CTR is up to the committer.</p></div>
         </div>



Mime
View raw message