PropertyPath now exposes the complete property named the resolution failed for in case it can't resolve a source String. It will expose the part of the Path from the deepest successful resolution result.
Changed the resolution algorithm to use a List instead of a Stack and a fresh instance of the former so that the nested recursion steps keep track of the correct resolution depths.
RepositoryConfigurationDelegate now registers the store-specific RepositoryConfigurationExtension as lazy-init BeanDefinition so that other parties can detect that definition.
We're now firing the component registration event manually in RepositoryBeanDefinitionParser as ParserContext.registerBeanComponent(…) registers the given BeanComponentDefinition with the registry. As we do that manually before this previously resulted in the BeanDefinition overriding the very same one and container warnings in turn.
We now synchronize the (seldom) writes to the isPropertyParameterCache HashMap in PreferredConstructor via a ReadWriteLock. We could as well have used a ConcurrentHashMap here without the need for manual locking but this would potentially waste memory for a mostly read-only data structure. We also anticipate potential multiple writes for the same property.
Original pull request: #86.
Parameters erroneously rejected @Param annotated query method parameters that were preceded by a non-bindable type (like Pageable or Sort) as it checked for a 0 index of the parameter. We now manually keep an index in the check itself and have removed the Parameter.isFirst() method as it's not used anywhere else.
We're now using the newly introduced method on ControllerLinkBuilderFactory that takes both a type and a method to forward the method the invocation is happening on independently from the method being invoked.
The property "location" should actually be "locations" since this attribute is read by org.springframework.data.repository.config.ResourceReaderRepositoryPopulatorBeanDefinitionParser.doParse(Element, BeanDefinitionBuilder).
The equals(…) and hashCode() methods of TypeVariableTypeInformation previously tried to evaluate the unresolved context of the type variable. This can cause issues in recursive type definitions as set up in the according test case. We now implement the methods based on the resolved type to makes sure we break the recursive lookup of PersistentEntity instances in AbstractMappingContext.
The erroneous lookup was actually caused by unresolved base types being added to the mapping context within the JPA project as the JPA meta-model also returns those types as managed types.
Related pull request: #84.
As SPR-11744 got fixed recently and will be available in Spring 3.2.9, we removed the guard in RepositoryBeanDefinitionRegistrarSupport which defaulted the environment in case it was not set by the container.
Related tickets: SPR-11744.
We now run the test case for the query method execution with Futures on Spring 3.2 as well (as SPR-11725 was fixed recently).
Related tickets: DATACMNS-489, DATACMNS-499, SPR-11725.
In case the repository method execution returns a collection that needs to be converted into a different collection (e.g. List -> Set) we erroneously ran into a NullableWrapper conversion. This was due to the fact that we only used the raw method return type, which caused the ObjectToCollectionConverter to kick in (as the target type's component type falls back to Object if we use raw types).
We're now using Spring's MethodParameter abstraction to create a TypeDescriptor for the method's return type which fully supports generics, so that the conversion check for NullableWrapper -> target type does not match the ObjectToCollectionWrapper.
Prepared the QueryExecutionConverters to be able to support recursive type conversion once we move to Spring 4 as TypeDescriptor exposes the ResolvedType as of this version so that we can inspect the type parameter of the wrapper type to invoke a nested conversion (e.g. Integer -> Optional<String> requires NullableWrapperTo(Guava|Jdk)OptionalConverter being invoked and in turn recursively convert the Integer to String).
We now explicitly discuss the case of referring to properties with underscores (e.g. first_name) in repository query methods.
Added missing language declaration for a code block.
We now also reflectively check for the presence of DefaultParameterNameDiscoverer. This allows the usage of the new reflection methods introduced in Java 8 if the user code is running on Spring 4.
Changed the name of the constant for the ParameterNameDiscoverer in Parameters to meet conventions for constants.
If a configuration class resides in the default package and no base package is defined in the @Enable…Repositories annotation we previously failed in extracting the package from the class name (as there is none).
We now use Spring's ClassUtils that correctly handles this case and returns an empty String for the default package.
Spring 4's GenericTypeResolver returns null when trying to resolve type arguments for types that do not fully resolve the generic types.
Related issues: SPR-11763.
Spring Buildmaster
Oliver Gierke
Thomas Darimont
Christoph Strobl
Oliver Gierke