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.
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.
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.
Version parsing failed when given version contained non-numeric parts (like 2.0.0-rc1). We now strip everything after the first non numeric part to create a logical version equivalent of the source String.
Original pull request: #81.
Previously, ParameterizedTypeInformation.hashCode() had been inconsistent to equals in case of a fully resolved parameterized type. This is now fixed by not including the parent reference in case a parameterized type is resolved completely.
Also, TypeDiscoverer.getActualType() does not return the component type for non-collection/non-maps anymore to make sure we don't accidentally unwrap parameterized types.
Added AnnotatedTypeScanner to easily scan for annotated types within a set of base packages. Picks up interfaces by default which had to be customized when using ClassPathScanningCanidateComponentProvider.
Added DirectFieldAccessFallbackBeanWrapper that will use direct field access for beans in case no accessor method can be found. This allows to easily implement bean property values through accessors first but using the field directly if the accessors aren't available.
Introduced AnnotationDetectionMethodCallback to easily find methods equipped with a given annotation.
Previously the map value type resolving algorithm checked the value type to be of type Map again to shortcut the resolution. We now weakened this to an assignment check and eagerly resolve the generic type if its bound on exactly that level already. If no concrete type argument can be found, we fall back to the general generics resolution mechanism.
In case of an unresolvable generic parameter in TypeDiscoverer's getTypeArgument(…) we check for a generic super type for the given bound and fall back to Object in case we find a parameterized type.
As of Spring 4, the GenericTypeResolver is more consistent in detecting raw types. It now returns null for both resolveTypeArguments(Set.class, Set.class) as well as resolveTypeArguments(Set.class, Iterable.class). The latter returns an array of Object.class in 3.x.
As this shouldn't make a pratical difference to actual clients (as they need to check for null anyway, we loosen the test case to be able to build Spring Data Commons against both Spring 3 and Spring 4.
Some polishing in the version detection in integration tests. Moved the Servlet 3.0 dependency into the Spring 4 profile.
We're now rejecting invalid constructor arguments handed to ClassTypeInformation, Part, PartTree and PropertyPath. Beyond that we skip the creation of a Part for an empty path segment, so that you don't end up with an invalid Part instance for a findAllByOrderByFooAsc.
So far the property lookup of a nested property path (e.g. "foo.bar") failed in cases the head property was not cached already. We now recursively resolve the type information even for an unpopulated cache.
