This commit fixes an issue where we fail to detect all type arguments from a given constructor. calling getGenericParameterTypes in some cases does not include all Types, we now explicitly iterate over the parameters and extract the parameterized type that is used for creating the TypeInformation.
Closes: #2313
Original pull request: #2314.
We now guard Slice conversion against potential ClassCastException using the proper condition grouping. Previously, the conversion could happen if the query is a slice query while the source was not a Slice.
Resolves#2296.
Mention that even when only using the CreatedDate & LastModifiedDate annotations it is mandatory to enable auditing.
Add sample of using auditing metadata within an embedded entity.
Closes#2283
Original pull request: #2285
We now cache the negative outcome of PreferredConstructor.isConstructorParameter(…) to avoid iterations and iterator allocations which roughly improves typical converter usage by roughly 32%.
Before:
Benchmark Mode Cnt Score Error Units
TypicalEntityReaderBenchmark.simpleEntityGeneratedConstructorAndField thrpt 10 6848447,474 ± 554354,377 ops/s
After
Benchmark Mode Cnt Score Error Units
TypicalEntityReaderBenchmark.simpleEntityGeneratedConstructorAndField thrpt 10 9071099,879 ± 1423166,087 ops/s
Closes#2295.
We now avoid the pre-computation of the base URI in PagedResourceAssemblerArgumentResolver as the actual assembler will fall back to using the URI of the current request by default anyway. The latter makes sure that request parameters, that are contained in the original requests appear in links created. If a controller wants to deviate from that behavior, they can create a dedicated link themselves and hand that to the assembler explicitly.
Fixes GH-2173, GH-452.
We now assign the repository field before resolving the persistent entity through the mapping context to avoid a potential NPE caused by a getObject(…) invocation through an application event.
Closes#2068
We now leniently skip parameter name resolution for types using unsigned types. The issue is caused by Kotlin's DefaultConstructorMarker that doesn't report a parameter name.
Closes#2215
We now check for double-nesting of JSON path evaluation results when the return type is a collection. If the result is double-wrapped and the nested object is a collection then we unwrap it.
Closes#2270
