Update template config section

src/main/antora/modules/ROOT/pages/mongodb/template-config.adoc

@@ -1,5 +1,5 @@
 [[mongo-template.instantiating]]
-== `MongoTemplate` Configuration
+= MongoTemplate Configuration
 
 You can use the following configuration to create and register an instance of `MongoTemplate`, as the following example shows:
 
@@ -57,26 +57,31 @@ XML::
 ----
 ======
 
-There are several overloaded constructors of `MongoTemplate`:
+There are several overloaded constructors of `MongoTemplate` and `ReactiveMongoTemplate`:
 
 * `MongoTemplate(MongoClient mongo, String databaseName)`: Takes the `MongoClient` object and the default database name to operate against.
 * `MongoTemplate(MongoDatabaseFactory mongoDbFactory)`: Takes a MongoDbFactory object that encapsulated the `MongoClient` object, database name, and username and password.
 * `MongoTemplate(MongoDatabaseFactory mongoDbFactory, MongoConverter mongoConverter)`: Adds a `MongoConverter` to use for mapping.
 
-Other optional properties that you might like to set when creating a `MongoTemplate` / `ReactiveMongoTemplate` are the default `WriteResultCheckingPolicy`, `WriteConcern`, and `ReadPreference` properties.
+Other optional properties that you might like to set when creating a `MongoTemplate` / `ReactiveMongoTemplate` are the default `WriteResultCheckingPolicy`, `WriteConcern`, `ReadPreference` and others listed below.
+
+[[mongo-template.read-preference]]
+== Default Read Preference
+
+The default read preference applied to read operations if no other preference was defined via the xref:mongodb/template-query-options.adoc#mongo.query.read-preference[Query].
 
 [[mongo-template.writeresultchecking]]
-== `WriteResultChecking` Policy
+== WriteResultChecking Policy
 
 When in development, it is handy to either log or throw an exception if the `com.mongodb.WriteResult` returned from any MongoDB operation contains an error. It is quite common to forget to do this during development and then end up with an application that looks like it runs successfully when, in fact, the database was not modified according to your expectations. You can set the `WriteResultChecking` property of `MongoTemplate` to one of the following values: `EXCEPTION` or `NONE`, to either throw an `Exception` or do nothing, respectively. The default is to use a `WriteResultChecking` value of `NONE`.
 
 [[mongo-template.writeconcern]]
-== `WriteConcern`
+== Default WriteConcern
 
 If it has not yet been specified through the driver at a higher level (such as `com.mongodb.client.MongoClient`), you can set the `com.mongodb.WriteConcern` property that the `MongoTemplate` uses for write operations. If the `WriteConcern` property is not set, it defaults to the one set in the MongoDB driver's DB or Collection setting.
 
 [[mongo-template.writeconcernresolver]]
-== `WriteConcernResolver`
+== WriteConcernResolver
 
 For more advanced cases where you want to set different `WriteConcern` values on a per-operation basis (for remove, update, insert, and save operations), a strategy interface called `WriteConcernResolver` can be configured on `MongoTemplate`. Since `MongoTemplate` is used to persist POJOs, the `WriteConcernResolver` lets you create a policy that can map a specific POJO class to a `WriteConcern` value. The following listing shows the  `WriteConcernResolver` interface:
 
@@ -91,9 +96,9 @@ You can use the `MongoAction` argument to determine the `WriteConcern` value or
 `MongoAction` contains the collection name being written to, the `java.lang.Class` of the POJO, the converted `Document`, the operation (`REMOVE`, `UPDATE`, `INSERT`, `INSERT_LIST`, or `SAVE`), and a few other pieces of contextual information.
 The following example shows two sets of classes getting different `WriteConcern` settings:
 
-[source]
+[source,java]
 ----
-private class MyAppWriteConcernResolver implements WriteConcernResolver {
+public class MyAppWriteConcernResolver implements WriteConcernResolver {
 
   @Override
   public WriteConcern resolve(MongoAction action) {
@@ -124,22 +129,39 @@ MongoOperations mongoTemplate(MongoClient mongoClient) {
 ----
 
 [[mongo-template.entity-callbacks-config]]
-== Configure `EntityCallbacks`
+== Configure EntityCallbacks
 
 Nest to lifecycle events the template invokes xref:mongodb/mapping/entity-callbacks.adoc[EntityCallbacks] which can be (if not auto configured) set via the template API.
 
-[source,java]
+[tabs]
+======
+Imperative::
++
+[source,java,indent=0,subs="verbatim,quotes",role="primary"]
 ----
 @Bean
 MongoOperations mongoTemplate(MongoClient mongoClient) {
-    MongoTemplate template = new MongoTemplate(mongoClient, "geospatial");
+    MongoTemplate template = new MongoTemplate(mongoClient, "...");
 	template.setEntityCallbacks(EntityCallbacks.create(...));
 	// ...
 }
 ----
 
+Reactive::
++
+[source,java,indent=0,subs="verbatim,quotes",role="secondary"]
+----
+@Bean
+ReactiveMongoOperations mongoTemplate(MongoClient mongoClient) {
+    ReactiveMongoTemplate template = new ReactiveMongoTemplate(mongoClient, "...");
+	template.setEntityCallbacks(ReactiveEntityCallbacks.create(...));
+	// ...
+}
+----
+======
+
 [[mongo-template.count-documents-config]]
-== Documents count configuration
+== Document count configuration
 
 By setting `MongoTemplate#useEstimatedCount(...)` to `true` _MongoTemplate#count(...)_ operations, that use an empty filter query, will be delegated to `estimatedCount`, as long as there is no transaction active and the template is not bound to a xref:mongodb/client-session-transactions.adoc[session].
 Please refer to to the xref:mongodb/template-document-count.adoc#mongo.query.count[Counting Documents] section for more information.