Also activated building on the new container infrastructure to use artifact caching.
Removed JDK 6 and 7 builds as the build on these VMs will fail due to the Optional stub causing NoClassDefFoundErrors.
We now make the field detected by the callback accessible so that the value lookup doesn't fail for private fields. Added a few more unit tests to verify behavior.
PageImpl now makes sure that the total given to the constructor is never less than then number of items given to make sure we do not mask broken count calculation by creating an actually invalid instance.
Related ticket: DATAMONGO-1120.
The initial setup of the type variable map now unfolds the detected types in the map to make sure we detect all type variables present in the current scope.
Added caching of component and map value TypeInformation instances to avoid repeated creation.
So far, the lookup of the type variable map was preferring the type variable maps detected on parent types in nested structures. This caused the concrete type variables in nested types not being considered correctly which caused the type resolution to fall back to the generic bounds.
We now accumulate the type variable maps to avoid having to lookup a certain map in the nesting hierarchy. The core fix is in ParentTypeAwareTypeInformation's constructor and mergeMaps(…) respectively. Simplified the handling of type variable maps and made proper use of generics throughout the class hierarchy.
DomainClassConverter now returns input when the source type is identical to the target type. Previously we erroneously tried to convert the sourceType to the idType of the targetType's backing repository. As a side effect we also avoid performing some unnecessary converter hops.
Original pull request: #101.
Clarified return values if predicates don't match or return multiple results (for the findOne(…) method). Copied summary to the @return tag.
Original pull request: #96.
Previously we only allowed to sort by QueryDsl path expressions. With this change we now also support ordering by operator expressions, e.g. yearMonth() on a date property.
Original pull request: #94.
The type detection for entity candidates of PersistentProperty instances now consistently handles collection types even if they're used als collection or map values.
Annotations used on both fields and accessors are now only rejected if they're Spring Data annotations (i.e. from the org.springframework.data namespace) and the configurations of these annotations differ.
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.
