QuerydslPredicateArgumentResolver now properly handles predicate lookups that result in null values. The semantics of a handler method parameter of type of Querydsl's Predicate have been tightened to always see a non-null Predicate by default. Users that want to handle the absence of predicates explicitly can opt into seeing null by annotating the parameter with @Nullable or use Optional<Predicate>.
QuerydslPredicateBuilder now consistently returns null in case the original parameter map is entirely empty or consists of only keys with empty value arrays as empty form submissions do. This partially reverts the work of DATACMNS-1168, which moved into the direction of returning a default Predicate value for empty maps in the first place. That however prevents us from producing empty Optionals.
Related tickets: DATACMNS-1168.
We now expose human readable resource descriptions based on RepositoryConfiguration and RepositoryConfigurationSource. Spring Boot uses those to describe problematic bean definitions in case it detects errors in the application setup.
We now return the content length as size of a Chunk if no Pageable has been used to create a Chunk. This makes the usage of a Chunk without an explicit Pageable work just like it was requested with the size of the given content.
We now skip PersistentPropertyPath instances pointing to auditing properties for which the path contains a collection or map path segment as the PersistentPropertyAccessor currently cannot handle those. A more extensive fix for that will be put in place for Moore but requires more extensive API changes which we don't want to ship in a Lovelace maintenance release.
Related tickets: DATACMNS-1461.
We now catch the MappingException produced by trying to set auditing property paths containing null intermediate segments and ignore those. A less expensive (non-Exception-based) approach is going to be introduced for Moore as it requires API changes to the property path setting APIs.
Related tickets: DATACMNS-1438.
PropertyAccessorClassGenerator now tries to look up the class to be generated first to potentially reuse an already existing one and avoid the recreation and registration of a same class which would trigger a Linkage error as a classloader cannot hold two classes with the same name.
The root of the problem is in the fact that the accessor instances are held in per instance caches in EntityInstantiators, so that multiple of those might try to create the same accessor class for a given domain type.
Previously, a module not exposing any entity identifying annotations would have claimed a repository definition and potentially overrode the bean definition of another store that was the proper claim in the first place. We have now changed this to abstain from a claim of the interface.
We' also tweaked the log output in the following cases:
1. If the module neither returns an identifying type nor entity identifying annotations, we now log a warning that a module does not support a multi-module setup and answer all assignment requests with false.
2. The info level warning indicating an interface has been dropped now reports which annotations or interface base types to use.
Original pull request: #411.
Related tickets: spring-projects/spring-boot#18721
We now elevate the primary annotation from the scanned repository bean definition to the one created for the repository factory. This previously got lost as the former is hidden behind the RepositoryConfiguration interface that previously didn't expose the primary nature of the underlying bean definition.
Original pull request: #410.
Add ReactivePageableHandlerMethodArgumentResolver and extract shared code from imperative PageableHandlerMethodArgumentResolver into PageableHandlerMethodArgumentResolverSupport.
Original pull request: #264.
Add ReactiveSortHandlerMethodArgumentResolver and extract shared code from imperative SortHandlerMethodArgumentResolver into SortHandlerMethodArgumentResolverSupport.
Original pull request: #264.
We now explicitly rejects null values for the Sort parameters in the constructor of PageRequest to avoid the creation of invalid instances if the IDE validation of nullability constraints is not in use.
We now remove partially populated PersistentEntity instances from the cache held in AbstractMappingContext as the creation could fail for other RuntimeExceptions other than a MappingException and we wouldn't want to keep the instances around in any case.
Slight refactorings in the unit tests so that we can easily create MappingContext instances that reject certain types with certain exceptions.
We now inspect returned Collections whether we need to convert these at all. If not, we skip conversion.
Also, allocate GenericConversionService only once for memory-efficiency.
We now avoid the allocation of an Optional instance in the lookup of a dynamic projection in ParameterAccessor. Also, Lazy now exposes a ….getNullable() to be favored over ….getOptional() for hot code paths.
Replaced Stream and Optional usage with for-loops and nullable return values. Reuse parameter names to avoid repeated annotation lookups. Reuse result from Parameters.getBindable(). Introduce ParametersParameterAccessor.getValues() to consistently reuse a single accessor instance allowing access to the unwrapped values. Introduce type cache to QueryExecutionConverters to quickly reject types that do not require wrapping. Avoid recalculation of QueryMethod.isCollectionQuery().
PersistentPropertyAccessor now has an overloaded method to pass in a TraversalContext that can be prepared to property handlers for PersistentProperties. During the traversal, the handler is called with the value for the property so that it can e.g. extract list elements, map values etc.
Replace AtTest(expected = …) and ExpectedException with the corresponding AssertJ assertThatExceptionOfType(…) and assertThatIllegalArgumentException().isThrownBy(…).
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
Removed Hamcrest and the `ExpectedException` rule and replaced it with AssertJ.
Removed now obsolete assertions checking against old Spring Framework versions.
Formatting.
Original pull request: #396.
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.
