A side effect of the fix for DATACMNS-1482 trigged source objects that already perfectly match the desired return type would still be subject to detailed inspection of potential conversions, which – by definition – will not kick in.
The code has now been changed to only trigger detailed inspection for collection values.
Related tickets: DATACMNS-1482.
If plain dots were submitted as elements in a Sort expression to be parsed by SortHandlerMethodArgumentResolver, those dots would be considered a property of the sort expression, which is of course wrong. We now drop property candidates solely consisting of dots and whitespace.
Add dedicated interfaces for sync and reactive usage.
Hide default implementation and use reflective callback method lookup.
Update documentation and add initial reference documentation snippet for store specific modules.
Original Pull Request: #332
This is a draft for a possible Entity Callback API heavily inspired by Spring Framework's Application Event listeners. Entity callbacks are callbacks for entities that allow for entity modification at certain check points such as before saving an entity or after loading it.
Entity callbacks consist of a marker-interface for all entity callback types and the EntityCallbacks API to dispatch callbacks.
Entity callbacks are picked up from the ApplicationContext and invoked sequentially according to their ordering.
Usage example:
AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext(MyConfig.class);
SimpleEntityCallbacks callbacks = new SimpleEntityCallbacks(ctx);
PersonDocument personDocument = new PersonDocument(null, "Walter", null);
PersonDocument afterCallback = callbacks.callback(personDocument, BeforeSaveCallback.class,
BeforeSaveCallback::onBeforeSave);
Mono<PersonDocument> afterCallback = callbacks.callbackLater(personDocument, ReactiveBeforeSaveCallback.class,
ReactiveBeforeSaveCallback::onBeforeSave);
@Configuration
static class MyConfig {
@Bean
BeforeSaveCallback<Person> personCallback() {
return object -> {
object.setSsn(object.getFirstName().length());
return object;
};
}
@Bean
MyReactiveBeforeSaveCallback callback() {
return new MyReactiveBeforeSaveCallback();
}
}
class MyReactiveBeforeSaveCallback implements ReactiveBeforeSaveCallback<Person> {
@Override
public Mono<Person> onBeforeSave(Person object) {
PersonDocument result = new PersonDocument(object.getFirstName().length(), object.getFirstName(),
object.getLastName());
return Mono.just(result);
}
}
Original Pull Request: #332
We now cache the BeanFactory lookup for EvaluationContextExtension within the ExtensionAwareEvalutationContextProvider to avoid (expensive) repeated context scans when creating the actual EvaluationContext.
Original pull request: #395.
Before this commit we haven't properly resolved methods on a root object provided by an EvaluationContextExtension that was using varargs. With a vararg method, the number of parameters handed into the method is not necessary equal to the number of parameters. We previously simply skipped methods with a different number of arguments. We now try direct matches first but calculate valid varargs alternatives in case that initial lookup fails and try to match those alternatives.
This lookup is implemented in ….util.ParameterTypes now and used by ….spel.spi.Function. The latter now also handles the actual invocation of those methods properly by collecting the trailing arguments into an array.
RepositoryBeanDefinitionRegistrarSupport now also overrides registerBeanDefinitions(AnnotationMetadata, BeanDefinitionRegistry) so that unit test in downstream modules still work.
Added defaulting of BeanNameGenerator in XmlRepositoryConfigurationSource so that we use an AnnotationBeanNameGenerator if a DefaultBeanNameGenerator is handed in.
Related tickets: spring-projects/spring-framework#22591
We now implement the newly introduced ImportBeanDefinitionRegistrar overload additional provided with a BeanNameGenerator configured for the import scanning. We forward this into our bean name generation infrastructure as fallback.
Related tickets: spring-projects/spring-framework#22591
We now expose a TypedSort that can use method handles to define properties to sort by.
Sort.sort(Person.class).by(Person::getName).ascending();
Related tickets: DATACMNS-1449.
Introduced MethodInvocationRecorder to record method invocations on types to obtain the property traversal those invocations represent.
Recorded<ZipCode> recorded = MethodInvocationRecorder.forProxyOf(Person.class)
.record(Person::getAddress)
.record(Address::getZipCode);
assertThat(recorded.getPropertyPath)).hasValue("address.zipCode");
We now explicitly check for the target type to be assignable to Streamable to opt into conversion. Without that check, every collection returned from a method declaring Iterable as return type would've been converted into a Streamable by accident.
Related ticket: DATACMNS-1430.
Various fast returns and the use of Class instead of TypeDescriptor led to e.g. List<BigDecimal> not getting properly converted to List<Integer> leading to unexpected ClassCastExceptions when the collection elements where accessed.
We now consider more than 16 immutable and nullable Kotlin properties per bucket in generated PropertyAccessors.
Previously only the first 16 properties were considered due to truncation of the defaulting bitmap. We used SIPUSH to render the defaulting mask in bytecode which is intended for 16 bit integers (short). Migrating to LDC (runtime constants) preserves the actual constant value of 32 bits and so we're considering now full buckets.
We now use Java Beans Introspector during default bean name derivation from class names. Previously, we used String.decapitalize(…) which decapitalizes always the first character. Java Beans do not decapitalize upper case sequences so a class name com.acme.UDPRepository translates to a bean name with UDPRepository instead of uDPRepository.
Original pull request: #325.
