XmlBeam 1.4.11 accidentally removed ProjectionFactory as public interface. Adapted our HttpMessageConverter implementation to make sure we still work on those versions.
Related ticket: https://github.com/SvenEwald/xmlbeam/issues/45
Marked all packages with Spring Frameworks @NonNullApi. Added Spring's @Nullable to methods, parameters and fields that take or produce null values. Adapted using code to make sure the IDE can evaluate the null flow properly. Fixed Javadoc in places where an invalid null handling policy was advertised. Strengthened null requirements for types that expose null-instances.
Removed null handling from converters for JodaTime and ThreeTenBP. Introduced factory methods Page.empty() and Page.empty(Pageable). Introduced default methods getRequiredGetter(), …Setter() and …Field() on PersistentProperty to allow non-nullable lookups of members. The same for TypeInformation.getrequiredActualType(), …SuperTypeInformation().
Tweaked PersistentPropertyCreator.addPropertiesForRemainingDescriptors() to filter unsuitable PropertyDescriptors before actually trying to create a Property instance from them as the new stronger nullability requirements would cause exceptions downstream.
Lazy.get() now expects a non-null return value. Clients being able to cope with null need to call ….orElse(…).
Original pull request: #232.
If you previously asked ProxyProjectionFactory for a proxy of an interface which the target instance already implements, it created a proxy although it could've returned the instance as is. It's now actually doing that avoiding superfluous proxy creation.
RepositoryFactoryBeanSupport.getRepositoryInformation() previously didn't consider any store-specific compositions (incl. store-specific fragments like the Querydsl support) as it just handed a fragment with the custom implementation to RepositoryFactorySupport.
This is now fixed by improving the API in RepositoryFactorySupport which now exposes a getRepositoryInformation(RepositoryMetadata, RepositoryFragments) which creates a fresh RepositoryComposition from the given RepositoryMetadata. Intermediate setup methods are still kept around but private as RepositoryFactorySupport.getRepository(…) still needs to forward the base RepositoryComposition to method interceptors for query result mapping.
As the calculation of a PersistentPropertyPath instances is rather expensive and they're heavily used in downstream mapping operations (e.g. query and fields mapping in MongoDB) we now cache the instances created per base type and property path.
Previously, RepositoryBeanNameGenerator applied the custom bean name lookup if the BeanDefinition given was not a ScannedGenericBeanDefinition. That in turn had been the case for custom implementation classes that were obtained through classpath scanning. With Spring 5 an index file can be used by the scanner, which in turn will cause AnnotatedGenericBeanDefinition instances being returned. That caused the code path to lookup the first constructor argument to kick in (usually used to obtain the repository interface from repository factory beans) and cause a NullPointerException.
We now forward AnnotatedBeanDefinitions as is and only apply the custom lookup for everything else, i.e. the bean definitions used for the factories.
Re-enabled test cases for handling of different date/time APIs in auditing. Tweaked the lookup of the last modified value to try to convert to LocalDateTime as well in case it's a subtype of the type requested. In combination with two newly introduced converters for local date type times in JodaTime and ThreeTenBP, this allows us to still convert legacy JodaTime and ThreeTenBP types to be used as well.
We now keep instances of ReturnedType around to avoid the repeated reflection inspection for constructor and parameter name detection for class types and projection information for interfaces.
Removed the deprecated implementation of ResourceLoaderAware in favor of BeanClassLoaderAware. Removed deprecated ProjectionFactory.getInputProperties() in favor of ….getProjectionInformation(). Removed the Java conditional to add a MethodInterceptor for default methods. Adapted test cases.
Introduced new ExampleMatcherAccessor in data.support in favor of the now deprecated one in data.repository.core to avoid a dependency into the repositories subsystem to work with examples in general.
Added Degraph based test in order to avoid future cyclic package dependency violations.
Original pull request: #230.
Related ticket: DATAMONGO-1721.
We now use a marker interface to store cache hits for conversion targets without requesting a conversion target in the conversion query. The dedicated marker type has an individual cache view and does not interfere with other types.
Previously we used Object as cache key which caused false positives due to assignability checks. If an earlier conversion query with a requested target type yielded a hit (e.g. negative hit), subsequent queries without a target type received the same answer. This might happen although the non-cached answer would return a different result.
Move MappingException from o.s.d.mapping.model to o.s.d.mapping package and use it for getRequired* methods in MappingContext instead of throwing IllegalArgumentException. Further on we’ve consolidated usage of IllegalArgumentException and IllegalStateException. Along that IllegalMappingException was removed in favor or MappingException.
BasicPersistentEntity now looks up all properties by annotation instead of just returning the first one found. We’ve kept the original methods behavior and updated the comment as well as introduced getPersistentProperties returning all matching properties.
We now override ClassPathScanningCandidateComponentProvider's getRegistry() to make sure custom conditions on repository candidates can use the currently available BeanDefinitionRegistry in their implementations. To achieve that we forward the BeanDefinitionRegistry at hand through the configuration infrastructure (both XML and annotation side of things).
Switched to use Optional<Object> to make nullability explicit. Keep the original ….convert(…) method around as deprecated default method so that clients can be migrated gradually.
We now use specified date formats for converting various date types to Strings and comparing them.
Before, in some cases toString() was used which strips trailing zeros, causing sporadic failures.
JDK9 changed the behaviour of Date related toString methods, making tests fail all the time.
Therefore this fix is required for executing tests with JDK9.
Original pull request: #228.
Changed RepositoryConfiguration to return Streamable over Iterable. A couple of code reorganizations, suppression of raw type. Turned abstract helper classes into interfaces where possible. A couple of typos in JavaDoc.
Original pull request: #222.
We now use RepositoryComposition as backing implementation for repository method calls to implementations. We now scan for repository fragments during the repository configuration phase. Fragment implementation candidates derive from the repository interface declaration, specifically the declared interfaces and their order. We scan the class path during fragment scan for each interface and add discovered fragments to the repository composition. The name of the implementation is derived from the simple name of the interface and the implementation suffix. Qualified fragments are top-level interface declarations that are not annotated with NoRepositoryBean. Inherited interfaces are not considered as fragment candidates.
We create a RepositoryComposition from the discovered fragments in the order of interface declaration in the repository interface and supply the composition to the actual repository creation.
Original pull request: #222.
We now accept Publisher<T> instead of Mono<T> in findById(…) and existsById(…). Users of a ReactiveStreams-based framework are no longer required to perform Publisher to Mono-adoption themselves but can pass a Publisher directly. Both methods use the first emitted value to issue their queries. Additional values are not consumed from the stream.
Original Pull Request: #226
Use Streamable in configuration APIs for more efficient, lazy traversal of source lists. Introduced SelectionSet.of(…) to move away from constructors. Avoid the use of null in SelectionSet.
Original pull request: #201.
When multiple repository implementations are found based on the class name, the one with a bean name matching the interfaces bean name + implementation postfix is picked. Includes support for CDI.
RepositoryBeanNameGenerator now no longer implements BeanNameGenerator since while it produces names it does not behave like the interface suggests, i.e. it can work without a BeanFactory in the first place. It now uses constructor injection and is package private.
Original pull request: #201.
Spring Data 2.0 is going GA after the feature freeze of RxJava 1. In prospect of its EOL it makes no sense to ship new APIs based on a library that goes towards EOL.
RxJava1CrudRepository and RxJava1SortingRepository are subject to removal in a future milestone.
All overloaded methods are now available in SPeL expressions. Among methods with identical argument list from different sources in the same extension (extension, root object, aliases) the last one in the order in parens wins. If there is more than one method for an application the following rules are applied: if there is one method with exact matching types in the argument list it is used, otherwise an exception is thrown.
Original pull request: #217.
Revert change to only invoke cleanup method if events have been exposed. We now again invoke the cleanup method for every aggregate. Changed the publication of events from the aggregate instances that were handed into the method to the ones the save method returns as the save call might return different object instances.
Cleanups in the unit tests. Moved newly introduced methods to the bottom of the test case class. Extracted method to set up mock method invocation.
Original pull request: #216.
We now make sure the event cleanup method is called on the aggregate root, not on the parameter object directly (as the latter might be a collection.
Original pull request: #216.
Replaced optional dependencies with Optional and explicit null checks with calls to ifPresent. Used Lambda style instead of anonymous classes where applicable. Converted Hamcrest matchers to AssertJ.
Minor improvements to formatting.
Original pull request: #208.
Introduced dedicated callback interfaces to customize the HandlerMethodArgumentResolver instances registered by SpringDataWebConfiguration. This allows bean definition registration of those customizer interfaces instead of having to extend a configuration class.
Original pull request: #208.
Previously we explicitly intercepted repository methods named save(…) and saveAll(…) which unfortunately results in custom variants of that (e.g. JpaRepository's saveAndFlush(…)) not causing event publication.
We now publish events for methods whose names start with save….
Introduced ConverterBuilder which exposes API to register Spring GenericConverters for the use with a store module's CustomConversions. This allows simple registration of such converters using Java 8 lambdas.
ConverterAware converters = ConverterBuilder.reading(String.class, Long.class,
it -> Long.valueOf(it)).andWriting(it -> Object::toString);
The setup can also be done from the reading side which would just need the method invocations inverted. The resulting ConverterAware will expose the registered converters so that they can be easily handed to a CustomConversions instance. Partial creation of either reading or writing converters is possible, too with the returned instance then only exposing one of the two converters.
CustomConversions now considers ConverterAware and treats them appropriately for ConvertiblePair registration as well as during the registration in the ConversionService. Tweaked parameter types in CustomConversions to rather accept a Collection<?> for the converters (previously List<?>). Also, registerConverterIn(…) now takes a ConverterRegistry over a GenericConversionService. Polished Javadoc and non-null assertions.
Original pull request: #209.
In case a repository method execution returns a JDK 8 Optional in the first place, the Optional instance had been wrapped into a third-party null-wrapper as is. We're now unwrapping the value held inside that optional and forward it to the value conversion.
We now follow a more consistent naming scheme for the methods in repository that are driven by the following guidelines:
* Methods referring to an identifier now all end on …ById(…).
* Methods taking or returning a collection are named …All(…)
That results in the following renames:
* findOne(…) -> findById(…)
* save(Iterable) -> saveAll(Iterable)
* findAll(Iterable<ID>) -> findAllById(…)
* delete(ID) -> deleteById(ID)
* delete(Iterable<T>) -> deleteAll(Iterable<T>)
* exists() -> existsById(…)
As a side-effect of that, we can now drop the Serializable requirement for identifiers.
Updated CRUD method detection to use the new naming scheme and moved the code to Java 8 streams and Optional. Adapted RepositoryInvoker API to reflect method name changes as well.
We now support Order creation with Order.asc(String) and Order.desc(String) factory methods as shortcut to constructor creation via new Order(Direction, String).
Sort.by(Order.asc("age"), Order.desc("name"));
Deprecated Order(String) constructor in favor of the Order.by(String) factory method. Replace references to new Order(String) with Order.by(String).
Original pull request: #211.
Used @RequiredArgsConstructor in a couple of places in favour of manually declared constructors. Removed obsolete factory methods on Range. Adapted test cases accordingly.
Original pull request: #212.
We now encapsulate a boundary in Range within a Bound value object. Bound consists of a value and whether the value is inclusive or exclusive. Boundaries without a value are unbounded. We introduced factory methods for Range and Boundary creation using primitives and a builder to build a Range.
Range<Long> range = Range.unbounded();
Range<Integer> range = Range.from(Bound.inclusive(10)).to(Bound.inclusive(20));
Range<Integer> range = Range.of(Bound.inclusive(10), Bound.inclusive(20));
Original pull request: #121.
