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.
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.
PageableHandlerMethodArgumentResolver.isFallbackPageable() now correctly guards against the fallback Pageable being null, a situation that's explicitly deemed valid in setFallbackPageable(…).
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.
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.
We now explicitly report the given object's type and the one expected in case of a mismatch when BasicPersistentEntity.getPropertyAccessor(…) is invoked.
We now also cache a failed property lookup so that we can return null on a subsequent call for the same invalid property name right away and don't have to reattempt the lookup unnecessarily.
The lookup for already available PersistentEntity instances now acquires a read lock to shield the execution from partially equipped PersistentEntity instances currently in creation from another thread.
Original pull request: #157.
ToEntityConverter.matches(…) now doesn't throw an exception anymore as it might be picked up by classpath scanning an the exception previously thrown causing the entire conversion attempt to abort.
We're now rather inspecting the ToEntityConverter in case the target type is a repository managed one and the ToIdConverter otherwise.
Simplified conditional expressions in DefaultRepositoryInformation. Reordered test method to reflect natural order of adding.
Original pull request: #162.
Add additional check for detecting customized method where method contains generics. Overriding methods without generics already works, this patch simply makes the behavior consistent.
Original pull request: #162.
We're now correctly stating that we're preferring the delete method that takes the entity as argument over the one taking the id to match what's actually implemented.
The translation of the list of actual type parameters into an array now uses the loop index correctly. Previously, it always used the first type parameter.
Added proper equals(…) and hashCode() methods to SyntheticParameterizedType to make sure instances created for the same type information and type parameters are considered equal.
Spring Operator
Spring Operator
Oliver Gierke
Spring Buildmaster
Mark Paluch
Oleksandr Mandryk
Kirill Gavrilov
Mikael Klamra
Terje Strand