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 <literal>cache.xml</literal> - + + 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