Merge pull request #43 from ljacomet/rendering-fixes

Multiple fixes in md files

documentation/2.10.1/pdf/index.md

@@ -3,7 +3,7 @@
 
 # Ehcache Documentation in PDF format
 
-####Current Product Documentation
+#### Current Product Documentation
 
 | |
 |:----|

documentation/2.10.2/pdf/index.md

@@ -3,7 +3,7 @@
 
 # Ehcache Documentation in PDF format
 
-####Current Product Documentation
+#### Current Product Documentation
 
 | |
 |:----|

documentation/2.10/pdf/index.md

@@ -3,7 +3,7 @@
 
 # Ehcache Documentation in PDF format
 
-####Current Product Documentation
+#### Current Product Documentation
 
 | |
 |:----|

documentation/2.7/apis/search.md

@@ -222,7 +222,7 @@ Assuming that we have previously created Person objects containing attributes su
 
 Given the code above, the newly put element would be indexed on values of name and age fields, but not gender. If, at a later time, you would like to start indexing the element data on gender, you would need to create a new `DynamicAttributesExtractor` instance that extracts that field for indexing.
 
-#####Dynamic Search Rules
+##### Dynamic Search Rules
 
 * In order to use the `DynamicAttributesExtractor`, the cache must be configured to be searchable and dynamically indexable (refer to [Making a Cache Searchable](/documentation/2.7/apis/search#making-a-cache-searchable) above). 
 
@@ -346,7 +346,7 @@ The GroupBy clause groups the results from `includeAttribute()` and allows aggre
 		String loc = singleResult.getAttribute(loc);
 
 
-####GroupBy Rules
+#### GroupBy Rules
 Grouping query results adds another step to the query--first results are returned, and second the results are grouped. This necessitates the following rules and considerations when using GroupBy:
 
 *  In a query with a GroupBy clause, any attribute specified using `includeAttribute()` should also be included in the GroupBy clause. 
@@ -467,7 +467,7 @@ Execute Time: 180ms
 </code></pre>
 
 
-##Best Practices for Optimizing Searches
+## Best Practices for Optimizing Searches
 1. Construct searches wisely by including only the data that is actually required. 
   *  Only use `includeKeys()` and/or `includeAttribute()` if those values are actually required for your application logic.
   *  If you don’t need values or attributes, be careful not to burden your queries with unnecessary work. For example, if `result.getValue()` is not called in the search results, then don't use `includeValues()` in the original query. 

documentation/2.7/code-samples.md

@@ -1,6 +1,6 @@
 ---
 ---
-#Code Samples
+# Code Samples
 
 
 

documentation/2.7/configuration/fast-restart.md

@@ -25,7 +25,7 @@ Cache persistence on disk is configured by adding the `<persistence>` sub-elemen
        <persistence strategy=”localRestartable|localTempSwap|none|distributed” synchronousWrites=”false|true”/>
     </cache>
 
-###Strategy Options
+### Strategy Options
 The options for the `strategy` attribute are:
 
 *  **"localRestartable"** &mdash; Enables the RestartStore and copies all cache entries (on-heap and/or off-heap) to disk. This option provides fast restartability with fault tolerant cache persistence on disk. This option is available for [BigMemory Go](http://terracotta.org/products/bigmemorygo) only.
@@ -36,7 +36,7 @@ The options for the `strategy` attribute are:
 
 *  **"none"** &mdash; Does not offload cache entries to disk. With this option, all of the cache is kept in memory. This is the default mode.
 
-###Synchronous Writes Options
+### Synchronous Writes Options
 If the `strategy` attribute is set to "localRestartable", then the `synchronousWrites` attribute may be configured. The options for `synchronousWrites` are:
 
 *  **synchronousWrites=”false”** &mdash; This option provides an eventually consistent copy of the cache on disk at all times. Writes to disk happen when efficient, and cache operations proceed without waiting for acknowledgement of writing to disk. After a restart, the cache is recovered as it was when last synced. This option is faster than `synchronousWrites="true"`, but after a crash, the last 2-3 seconds of written data may be lost. 
@@ -50,15 +50,15 @@ If the `strategy` attribute is set to "localRestartable", then the `synchronousW
 **Note**: The `synchronousWrites` attribute is also available in the `<terracotta>` sub-element. If configured in both places, it must have the same value.  
 
 
-###DiskStore Path
+### DiskStore Path
 The path to the directory where any required disk files will be created is configured with the `<diskStore>` sub-element of the Ehcache configuration. 
 
 For "localTempSwap", if the DiskStore path is not specified, a default path is used for the disk storage tier, and the default path will be auto-resolved in the case of a conflict with another CacheManager.
 
 ## Configuration Examples
 This section presents possible disk usage configurations for open-source Ehcache 2.6 and higher.
 
-###Temporary Disk Storage
+### Temporary Disk Storage
 
 The "localTempSwap" persistence strategy allows the cache to use the local disk during cache operation. The disk storage is temporary and is cleared after a restart. 
 
@@ -71,15 +71,15 @@ The "localTempSwap" persistence strategy allows the cache to use the local disk
 
 **Note**: With the "localTempSwap" strategy, you can use `maxEntriesLocalDisk` or `maxBytesLocalDisk` at either the Cache or CacheManager level to control the size of the disk tier. 
 
-###In-memory Only Cache
+### In-memory Only Cache
 When the persistence strategy is "none", all cache stays in memory (with no overflow to disk nor persistence on disk).
 
     <cache>
       <persistence strategy=”none”/>
     </cache>	
         
 
-###Programmatic Configuration Example
+### Programmatic Configuration Example
 The following is an example of how to programmatically configure cache persistence on disk:
 
     Configuration cacheManagerConfig = new Configuration()
@@ -99,7 +99,7 @@ The following is an example of how to programmatically configure cache persisten
 
 
 ## Compatibility with Previous Versions
-###Comparison of Disk Usage Options
+### Comparison of Disk Usage Options
 The following table summarizes the configuration options for disk usage in Ehcache 2.6 and higher as compared with previous versions.
 
 | Disk Usage | Ehcache 2.6 (and higher) | Ehcache 2.5 and Earlier |
@@ -117,7 +117,7 @@ The following table summarizes the configuration options for disk usage in Ehcac
 **In Ehcache 2.5 and earlier, cache persistence on disk for standalone Ehcache is configured with the `overflowToDisk` and `diskPersistent` attributes. If both are set to "true", cached data is saved to disk asynchronously and can be recovered after a clean shutdown or planned flush. To prevent corrupt or inconsistent data from being returned, checking measures are performed upon a restart, and if any discrepancy is found, the cache that was stored on disk is emptied and must be reloaded from the data source.
 
 
-###Upgrading from Ehcache 2.5 and Earlier
+### Upgrading from Ehcache 2.5 and Earlier
 
 After upgrading from a version of Ehcache previous to 2.6, it is strongly recommended to add the `<persistence>` sub-element to your cache configuration, and to delete, disable, or edit out disk persistence configuration elements from previous versions. The previous elements include:
 

documentation/2.7/integrations/coldfusion.md

@@ -4,7 +4,7 @@
 
 
 
-##Introduction
+## Introduction
 ColdFusion ships with BigMemory Go's Ehcache. The ColdFusion community has actively engaged with Ehcache and have put out lots of great blogs. Here are three to get you
 started.
 For a short introduction, see [Raymond Camden's blog](http://www.coldfusionjedi.com/index.cfm/2009/7/18/ColdFusion-9-and-Caching-Enhancements).

documentation/2.7/integrations/glassfish.md

@@ -4,7 +4,7 @@
 
 
 
-##Introduction
+## Introduction
 The maintainer uses Ehcache in production with Glassfish. This page explains how to package a sample application using Ehcache and deploy to Glassfish.
 
 ## Versions

documentation/2.7/integrations/googleappengine.md

@@ -4,7 +4,7 @@
 
 
 
-##Introduction
+## Introduction
 The ehcache-googleappengine module combines the speed of Ehcache with the scale of Google's memcache and provide the best of both worlds:
 
 * Speed - Ehcache cache operations take a few microseconds, versus around 60ms for Google's provided client-server cache, memcacheg.

documentation/2.7/integrations/hibernate-upgrade.md

@@ -4,7 +4,7 @@
 
 
 
-##Introduction
+## Introduction
 This page contains notes for users upgrading from older versions Ehcache prior to 2.0.
 
 ## Support for Hibernate 3.3 SPI