RepositoryFactoryBeanSupport now declares both a default constructor as well as one taking the repository interface as argument like we're going to progress in Ingalls. This allows implementations to tweak their Hopper compatible extensions of the class to also declare both constructors. That causes them to stay compatible with Hopper (which will use the setter) but also run on Ingalls which will use constructor injection.
Previously a null value was added to the list of associations if it was handed to BasicaPersistentEntity.addAssociation(…). We now drop those null values and log a warning as it usually indicates a MappingContext implementation identifying a property as association but subsequently failing to look it up.
We now try to look up a target class method based on concrete name and parameter type before falling back on the more expensive type matches. This also eliminates the possibility of invalid method matches as described in the ticket.
We now no longer attempt query creation for static methods declared on a repository interface. This allows static method usage inside of repository interfaces.
interface PersonRepository extends CrudRepository<Person, String> {
static String createId() {
// …
}
default Person findPerson() {
return findOne(createId());
}
}
PageableHandlerMethodArgumentResolver.isFallbackPageable() now correctly guards against the fallback Pageable being null, a situation that's explicitly deemed valid in setFallbackPageable(…).
This commit changes some ArrayList initializations to use an initial capacity and avoids the unnecessary fetch of the return type of a method in Parameter.isDynamicProjectionParameter().
Original pull request: #180.
The special case of an Iterable parameter doesn't have to be handled explicitly anymore so that we can simplify the type match check in DefaultRepositoryInformation.
Related ticket: DATACMNS-912.
QueryExecutionResultHandler now explicitly handles null values for query methods returning Maps by returning an empty Map. This can be the case if a query is supposed to produce a Map (a single result) but doesn't actually yield any results at all.
We now correctly check the bounds of generic methods if we deal with a type variable found as method parameter. Introduced different code paths for type and method level generics so that the latter is explicitly checking all bounds available.
The proxies created for projections now defensively mask getDecoratedClass(), a method declared on DecoratingProxy, an interface that JDK proxies on Spring 4.3 will implement.
Previously, calls to ParameterizedTypeInformation.getMapValueType() caused an infinite recursion when invoked on a type information that was not a map type. This lead to a StackOverflowError.
We now call the super method doGetMapValueType() instead of calling the entry super method getMapValueType() and return by that null in case the map value type is not resolvable.
Original pull request: #176.
We now provide equals(…) and hashCode() methods for GenericPropertyMatcher, PropertySpecifier and PropertySpecifiers so that they can be compared and used in sets.
Original pull request: #175.
If the same generic type was used on recursively nested generics declarations, like this:
class GenericType<T> {}
class Nested extends GenericType<String> {}
class Concrete extends GenericType<Nested> {}
our traversal of the generics discovered T bound to String in Nested and as that is extending GenericType as well, the T detected here is the same instance as the T within the map discovered for Concrete. As we previously added the nested types after we added the original entry, the nested discovery overwrote the more local one.
We now make sure the detected nested type variable mappings don't overwrite already existing ones.
Previously TransactionalRepositoryFactoryBeanSupport.setBeanFactory(…) didn't invoke the method of the super class preventing the BeanFactory to be propagated to the repository factory resulting in the ProjectionFactory implementation created being unaware of the BeanFactory and thus no bean references being available in projection interfaces.
Improved the dot-path translation of existing Querydsl Path instances by not relying on the toString() representation of the metadata but manually traversing the elements up to the root. Extracted the translation method into QueryDslUtils.
Furthermore, we now automatically insert an CollectionPathBase.any() step for Path instances of that type when reifying the paths from request attributes.