Short answer... No.

Only when a user defines Regions, Disk Stores, or other components using GemFire's native cache.xml configuration file in addition to using the SpringContextBootstrappingInitializer to bootstrap, configure and initialize a Spring container and context inside GemFire, likely to augment the GemFire native config with components from Spring config (using the SDG XML namespace, or even other components... Integration, Batch, whatever) that the elements in the native cache.xml configuration file must be declared in the order as defined in the GemFire Cache XML DTD.  

I.e., if a using the <region> element in cache.xml, then it must declared before the <initializer> element/block when using the SpringContextBootstrappingInitializer Declarable GemFire component, to startup a Spring container in GemFire.

Currently, the cache7_5 DTD defines the <cache> element and correct subelement order as...

```
<!ELEMENT cache (
    cache-transaction-manager?,
    dynamic-region-factory?,
    gateway-hub*,
    gateway-sender*,
    gateway-receiver*,
    gateway-conflict-resolver?,
    async-event-queue*,
    cache-server*,
    bridge-server*,
    pool*,
    disk-store*,
    pdx?,
    hdfs-store*,
    region-attributes*,
    (jndi-bindings | region | vm-root-region)*,
    function-service?,
    resource-manager?,
    serialization-registration?,
    backup*,
    initializer?
    )>
```

As you can see, the <initializer> subelement of <cache> is the last declared element/block in cache.xml.

However, I think our "recommended" approach to users should be to only use enough of GemFire' native cache.xml configuration meta-data to bootstrap, configure and initialize a Spring container and context inside GemFire.  Therefore, "nearly all" configuration should be handled in Spring.  I explain this more below.  But essentially, the following cache.xml, based on the "recommended" approach is valid (I even tested this from Gfsh)...

```
<?xml version="1.0"?>
<!DOCTYPE cache PUBLIC  "-//GemStone Systems, Inc.//GemFire Declarative Caching 7.0//EN"
  "http://www.gemstone.com/dtd/cache7_0.dtd">
<cache>
  <initializer>
    <class-name>org.springframework.data.gemfire.support.SpringContextBootstrappingInitializer</class-name>
    <parameter name="contextConfigLocations">
      <string>
        classpath:org/spring/data/gemfire/app/initializer-gemfire-context.xml
      </string>
    </parameter>
  </initializer>
</cache>
```

I say "nearly all" because this approach (using GemFire to bootstrap a Spring container and context) has 1 very significant limitation and problem.

Essentially, the SDG XML <cache> namespace element is effectively reduced to a "lookup" for the purposes of defining a Cache bean reference in the Spring context for defining other GemFire components with SDG's XML namespace (such as Regions, Disk Stores, Gateways, whatever).  Therefore none of the <cache> namespace element's attributes and subelements can be used to configure the Cache, because it already exists by the time the Initializer element/block from native GemFire config is parsed/processed, and since the Cache is a Singleton, the CacheFactoryBean effectively and appropriately does a lookup and finds an existing Cache reference, therefore ignoring any configuration in the SDG XML config meta-data.

This is the main reason why I am pushing and arguing for the Spring container be in control of bootstrapping, configuring and initializing GemFire, instead of the other way around (this PR).  The real work is to modify the 'start server' Gfsh command to take a 'spring-context-config-location' option specifying Spring XML configuration meta-data files to start a Spring container that might contain SDG XML config to bootstrap GemFire inside the Spring container.

The other problem is that when a user does use the GemFire's native cache.xml config to declare Regions and other GemFire components, these object may declare the use of CacheListeners, Loaders, Writers and so that Spring, using SDG, can normally auto-wire by way of extending the WiringDeclarableSupport class (http://docs.spring.io/spring-data-gemfire/docs/1.3.3.RELEASE/reference/html/apis.html#apis:declarable).

However, this can no long happen since we have a chicken and egg problem.  If the user uses Spring to bootstrap GemFire with the SDG XML namespace, Spring will process the context configuration files and know of all beans (definitions) before the GemFire Cache is created, therefore enabling Spring to wire any CacheListeners, Loaders, Writers, etc defined in native cache.xml, such as when using the SDG XML namespace <cache> element's 'cache-xml-location' attribute, because the Spring container has been configured.  Of course, the GemFire  objects (CacheListeners and so on) must extends WiringDeclarableSupport.

However, this no longer works when GemFire bootstraps the Spring container with the SpringContextBootstrappingInitializer since GemFire has already created all the object/components, Listeners, Loaders, Writers, etc, etc, and is the main reason I created the "LazyWiringDeclarableSupport" class, which implements the Observer/Observable design pattern with Spring container's application event notification subsystem.

Anyway, these 2 reasons alone are enough to warrant Spring always being in control of booting GemFire from a Spring context, IMO.

Though, as I have shown, above, a minimal ("recommended") amount of GemFire native cache.xml, albeit with limitations, can be used to kick start the process and handle most configuration appropriately with Spring.

Again, additional details and information is contained in SGF-248: https://jira.springsource.org/browse/SGF-248