diff --git a/docs/src/docbkx/reference/bootstrap.xml b/docs/src/docbkx/reference/bootstrap.xml
index 38151506..8e2a7db4 100644
--- a/docs/src/docbkx/reference/bootstrap.xml
+++ b/docs/src/docbkx/reference/bootstrap.xml
@@ -534,14 +534,14 @@ redundancy. Each copy provides extra backup at the expense of extra storages.
-
+
-
+
]]>
Just as the other region types, client-region allows defining CacheListeners. It also relies on the same naming conventions
@@ -557,10 +557,10 @@ redundancy. Each copy provides extra backup at the expense of extra storages.
-
-
-
-
+
+
+
+
]]>
@@ -663,8 +663,7 @@ redundancy. Each copy provides extra backup at the expense of extra storages.
-]]>
-
+]]>
By using the attribute factories above, one can reduce the size of the cache.xml or even eliminate it all together.
@@ -672,7 +671,14 @@ redundancy. Each copy provides extra backup at the expense of extra storages.
Advantages of using Spring over GemFire cache.xml
-
+
+ With SGF, GemFire regions, pools and cache can be configured either through Spring or directly inside GemFire, native, cache.xml file. While both are valid
+ approaches, it's worth pointing out that Spring's powerful DI container and AOP functionality makes it very easy to wire GemFire into an application. For example configuring a region
+ cache loader, listener and writer through the Spring container is preferred since the same instances can be reused across multiple regions and additionally are either to configure
+ due to the presence of the DI and eliminates the need of implementing GemFire's Declarable interface (see on chapter
+ on how you can still use them yet benefit from Spring's DI container).
+
+ Whatever route one chooses to go, SGF supports both approaches allowing for easy migrate between them without forcing an upfront decision.
\ No newline at end of file