Fixes JIRA issue SGF-259 involving circular dependencies between an Async Event Queue and corresponding, registered Async Event Listener.
General test code cleanup and optimizations along with other code refactoring.
Test changes to properly assert Region Eviction Threshold attribute settings for various LRU Eviction Action algorithms like (ENTRY_COUNT, HEAP and MEMORY).
Additional test changes based on whether mocking is enabled or not.
Add support for marking a repository with @Region rather than the entity
Review and test changes for PR #55, which involves storing an entity to multiple Regions in the GemFire Cache.
Adding additional test cases to re-inforce my feedback comments, specifically testing the Region 'Key' type and Entity '@Id property' type mismatch and constraint check in the GemfireRepositoryFactory.getTemplate(..) method, lines 128 and 129.
Implements JIRA ticket SGF-261 allowing an application domain object, or rather entity to be persisted to multiple Regions in the GemFire Cache.
Completes JIRA ticket SGF-256 and upgrades Spring Data GemFire to Spring Framework 3.2.8 and Spring Data Commons 1.8.0.
Completes JIRA ticket SGF-204 changing the default behavior of peer and client Region types to not perform a lookup first of an existing Region of the same name/path if the Region was created and configured using native cache.xml in GemFire in addition Spring config.
Refactored RegionFactoryBean and ParsingUtils classes to simplify the code.  Specifically, simplified the logic in the parseExpiration and parseCustomExpiration methods while preserving functional behavior.
Added specific Spring Converter implementations for GemFire RegionShortcut and ClientRegionShortcut enumerated value classes.
Implements SGF-88 - Region Shortcuts; Implements SGF-257 - Strict types in the SDG XSD for Region data-policy and shortcut attributes; Fixes SGF-258 - missing data-policy attribute for Partitioned Regions; Fixes SGF-263 - ineffective application of disk-synchronous attribute setting on Region bean definitions defined with SDG XML namespace.
Implements SGF-204 changing the default behavior or Region lookups.
Early solution for SGF-248 concerning bootstrapping a Spring ApplicationContext inside a GemFire Server-based JVM process when starting the GemFire Server from Gfsh.
Renaming the SpringContextBootsrappingInitializerTest to SpringContextBootstrappingInitializerIntegrationTest to reflect the fact that the test class is actually an 'integration' test.  Also renamed the cache-with-initializer.xml GemFire native configuration file to cache-with-spring-context-bootstrap-initializer.xml to indicate that we are using GemFire to bootstrap a Spring container.
Completed all testing and interface/functional changes for SGF-248 - Bootstrapping a Spring ApplicationContext with GemFire.
Added support to the SpringContextBootstrappingInitializer class for component scanning given a set of base packages to scan.  Refactored LazyWiringDeclarableSupport to implement the DisposableBean interface in order for any extending bean component to unregister itself from the SpringContextBootstrappingInitializer to stop receiving ApplicationContext event notifications when destroyed.  Fully tested the application component scanning and configuration using Annotations and JavaConfig-based configuration, uplifting some of the application components (UserDao, UserService, etc) from the integration test and adding a UserApplicationConfiguration @Configuration component in order to test this functionlity properly.
Added appropriate synchronization around application event notification using the Spring ApplicationContext and ApplicationEventMulticaster.  In addition, added support for late ContextRefreshedEvent notifications in the case where ApplicationListeners are registered after the ConfigurableApplicationContext has already been constructed, configured, initialized and refreshed.  This latest feature is meant to support updates planned in the 7.5 GemFire release to the Gfsh 'deploy' command dynamically deploying and initializing Declarables in the JAR file.  It is possible that Declarables are created and initialized in an unspecified order given there is not equivalent to Spring's Ordered interface in GemFire.