DATACMNS-526 - Improved configuration behavior in multi-store scenarios.

We now apply a stricter repository interface selection if we detect multiple Spring Data modules to be in the classpath to avoid the repository scanning accidentally overriding each others definitions or even picking up interfaces they weren't intended to manage.

The detection is based on a type scan in dedicated base package where subtypes of RepositoryFactorySupport usually reside. If more than one type is found, we activate strict scanning.

The strict check is actually implemented in RepositoryConfigurationExtensionSupport to be accessible for store implementations. By default we try to load the repository candidate interface and inspect the managed domain types for a collection of annotations (see RepositoryConfigurationExtensionSupport.getIdentifyingAnnotations()). Implementors still have the chance to customize the behavior by overriding isStrictRepositoryCandidate(…).

We also introduced a getModuleName() to be able to create better logging output in terms of repository registration. Moved registration of RepositoryConfigurationExtension as Spring bean into the base types for XML and annotation configuration support to make sure they only kick in if explicit configuration is used.

src/main/java/org/springframework/data/config/TypeFilterParser.java

@@ -1,5 +1,5 @@
 /*
- * Copyright 2010-2012 the original author or authors.
+ * Copyright 2010-2014 the original author or authors.
  *
  * Licensed under the Apache License, Version 2.0 (the "License");
  * you may not use this file except in compliance with the License.
@@ -82,7 +82,7 @@ public class TypeFilterParser {
 	 * @param type must not be {@literal null}.
 	 * @return
 	 */
-	public Iterable<TypeFilter> parseTypeFilters(Element element, Type type) {
+	public Collection<TypeFilter> parseTypeFilters(Element element, Type type) {
 
 		NodeList nodeList = element.getChildNodes();
 		Collection<TypeFilter> filters = new HashSet<TypeFilter>();