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.
