Nullable wrappers such as Java 8 Optional, Guava Optional, Scala Option and Vavr Option are now handled in NullableWrapperConverters and are no longer coupled to QueryExecutionConverters so that this functionality can be reused.
Original Pull Request: #459
ReactiveWrappers doesn't belong in there in the first place so we're removing ReactiveWrappers support from QueryExecutionConverters so ReactiveWrappers is used from parts that need to be reactive-aware.
Original Pull Request: #459
For some reason, calling Flux.from(…) in its own, static method, heals NoClassDefFoundError even though the method is not used during runtime nor Publisher is defined in a method signature.
CloseableIterator now allows construction of a Stream that is associated with a close hook to release resources after its use.
CloseableIterator<Person> iterator = …;
try (Stream<Person> stream = iterator.stream()) {
assertThat(stream.count()).isEqualTo(3);
}
Avoid reuse of Lazy instances for (Sort|Pageable)HandlerMethodArgumentResolver and consistently use those to avoid breaking API changes in configuration classes.
We now use @Configuration(proxyBeanMethods = false) and use BeanFactory bean lookups to avoid CGlib proxy creation.
Using Spring's BeanProvider.getIfUnique(…) instead of catching NoSuchBeanDefinitionException.
We now correctly determine the parameter count instead of returning a stating no-op object to correctly compare whether the target method uses the same count of arguments.
Original Pull Request: #455.
Move Publisher decoration into its own type to avoid a static reference to Publisher. Fix imperative repository MethodLookups.
Original Pull Request: #455.
We now allow for registering RepositoryMethodInvocationListeners to notify listeners upon repository method invocations (query methods and repository fragments). Listeners are notified upon method completion reporting the repository interface, the invoked methods, duration, outcome and arguments.
Original Pull Request: #455
Revert bean name change so all nested repository interface components (repository bean, fragment bean, legacy custom implementation bean) remain prefixed with their enclosing type name.
Adopt tests. Add test for RepositoryBeanDefinitionRegistrar. Extend documentation.
Original pull request: #460.
Problem: while repository and fragment interfaces are discovered
correctly (provided that considerNestedRepositories=true), their
implementations are not found/registered despite proper class naming.
Cause: DefaultImplementationLookupConfiguration works in such way that
for nested interface (i.e. one whose class name includes name of the
enclosing class) expected implementation class name is built including
that enclosing class name. In the same time actual implementation class
names are always "localized" (i.e. stripped from enclosing class name,
if any) before matching. This makes matching implementation classes
against nested interface impossible.
Solution: when building expected implementation class name, use "local"
interface class name, so that it can match any implementation class that
follows naming convention "SimpleInterfaceName" + "ImplemenetationPostfix".
Original pull request: #460.
We now use a dedicated GetOptions instance for the lookup of the parent path in case SetOptions is defined to skip nulls so that the lookup does not fail if the parent path contains a null value.
Use a more lenient approach, that allows metadata creation, when looking up persistent entities. This allows eg. a configured AuditingHandler to kick in without having to register an initial entity set in first place.
Original pull request: #462.
Use KotlinDetector instead of ReflectionUtils.isKotlinClass(…). Use replacement MethodParameter(…).withContainingClass(…) instead of GenericTypeResolver.resolveParameterType(…). Use MergedAnnotations.from(…).isPresent(…) instead of AnnotationUtils.isAnnotationMetaPresent(…).
kotlin.Unit is now considered a simple type to avoid PersistentEntity creation.
ReflectionUtils.isVoid(…) now encapsulates the check so that calling code doesn't need to check if Kotlin is on the class path.
findRequiredMethod(…) now prefers regular methods over synthetic/bridge methods. This refinement is required for newer Java versions that create synthetic bridge methods using the interface's return type. For SpEL extension introspection we're looking for the most specific return type that may be declared in the extension.
Original Pull Request: #454
Mark Paluch
Greg L. Turnquist
Oliver Drotbohm
Christoph Strobl
Kyrylo Merzlikin
DK Lee