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 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.
$ Conflicts:
$ src/main/java/org/springframework/data/domain/PageRequest.java
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.
DATACMNS-783 introduced code to specialize a raw type containing generics with the type information from it's context so that it can be established if only the raw type has been e.g. stored as type hint in a store (SomeType<T> stored as SomeType and T needing to be reestablished from the context). That application of the context unfortunately did not consider that the raw type might carry generics information itself, like `SomeType extends Foo<String, Integer>`.
We've now changed the specialization algorithm so that the the target type is being looked at in the context of the type used for the assignment (e.g. `Foo<T, ID> foo`). If that assignment fully resolves the declared type, we just outright use the given type as it by definition carries all generics information plus better type information in the first place.
If the type to specialize on is only partially expanding the generics we now create a synthetic type to merge the generics information. I.e. a `SomeType<T> extends Foo<T, Integer>` stored as SomeType would still resolve ID to Integer but capture T from the context including all potentially declared bounds.
Related tickets: DATACMNS-783, DATACMNS-1138.
To resolve XSD files properly from the classpath, their HTTPS reference must be present in the spring.schemas to avoid internet interaction for resolving an XSD file.
Christoph Strobl
Oliver Drotbohm
Mark Paluch
Jens Schauder
Wilds
Bruno Lellis
Roland Weisleder
Matthias Merdes
Jef LeCompte
Michael Simons
Stas
Greg Turnquist
Sangwoo Lee