Introduced overload for CustomRepositoryImplementationDetector.detectCustomImplementation(…) to take a RepositoryConfiguration to simplify the invocation from the Spring container related client. Further simplification to unify invocations also from the CDI implementation to be done in 2.0.
Expose getExcludeFilter() on RepositoryConfiguration to not have to inspect the configuration source on clients.
Formatting and Javadoc. Missing license headers in newly created types.
Original pull request: #195.
The detection algorithm for custom repository implementations now considers the exclude filters declared in the overall repository setup (XML and annotations).
Original pull request: #195.
Use simple if manually throwing the IllegalArgumentException instead of an Assert. Should be replaced with an Assert accepting Supplier when moving to Spring 5 and Java 8.
Original pull request: #198.
ProxyingHandlerMethodArgumentResolver is now more lenient when it comes to which types to support for proxying. As indicated in the ticket, we've been to aggressive opting in for all interfaces which - depending on the order of converter registrations - caused us interfering with other interface based resolutions (e.g. in Spring Mobile, Security etc.).
We now only aggressively kick in if either the type is not a Spring Framework or native Java one. This should leave user defined types still be accepted whereas the types we previously erroneously interfered with should now be ignored.
Entities without an identifier previously an exception because the IsNewStrategyFactory wasn't able to determine a strategy even if there was no auditing to be applied in the first place.
We now eagerly check for auditability and skip the lookup for an IsNewStrategy completely in case that check returns false.
Related pull request: #189.
We now exclude getter methods that are default methods from the consideration which properties of a projection interface are considered input properties in the first place.
Unfortunately no tests for this one as we can't declare default methods in our codebase requiring JDK 6 compatibility.
We now manually filter already gathered property names in ReturnedInterface.getInputProperties() as we have to deal with duplications for properties with the same name at different levels of the inheritance hierarchy.
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.