Previously, the publication of the event that indicated a PersistentEntity having been added to it took place before the write lock over the entities had been released. We now keep the lock smaller and publish the addition event *after* the lock has been released.
Tweaked newly introduced RepositoryConfiguration.getImplementationBasePackage() to not require a parameter but use internal information instead (the repository interface in DefaultRepositoryConfiguration).
Original pull request: #248.
Custom repository implementation scan uses the repository interface package and its subpackages and no longer scans all configured base packages. Scan for fragment implementations defaults to the fragment interface package. Using the interface package for scanning aligns the behavior with the documentation.
Declaring the implementation along with the interface in the same package is an established design pattern allowing to limit the scanning scope. A limited scope improves scanning performance as it can skip elements on the classpath, that do not provide that particular package.
Previously, we scanned for implementations using the configured base packages that were also used to discover repository interfaces. These base packages can be broader for applications that spread repository interfaces across multiple packages.
Original pull request: #248.
When trying to determine if a parameter is a dynamic projection parameter, i.e. the parameter of type Class that determines the projection to use, now the type parameter of that method parameter gets compared with the unwrapped return type. Therefore this works now not only for Maps and Collections but also for the various wrappers defined in QueryExecutionConverters.
Moved the method for unwrapping the return type from AbstractRepositoryMetadata to QueryExecutionConverters in order to make it available to every class needing it. This also puts it closer to the data it is working on.
Original pull request: #249.
We now prefer to inspect the arguments handed to save(…) methods over inspecting the return value as the invocation of the actual method is free to exchange the instance handed into it and return a completely new one with the events contained in the parameter completely wiped.
We're now trying to look up a uniquely available ObjectMapper instance from the application context falling back to a simple new instance in case none can be found.
We now define generated PropertyAccessor classes using the entities' protection domain. Reusing the same protection domain preserves the same security and visibility rules as if the class was shipped within the source of the class loaded and prevents SecurityExceptions caused by signature certificate mismatch.
Previously we uses the protection domain of the PersistentEntity class implementation. This mismatch caused SecurityExceptions if the JAR file of the PersistentEntity was signed but not the JAR file where the domain class resides.
Original pull request: #240.
If a JSONPath expression is using a path not available in the backing payload we now return null rather than letting the PathNotFoundException propagate.
Methods for domain event registration and access are now not following bean semantics anymore to avoid those accidentally leaking into formats that use the bean spec (e.g. Jackson to produce JSON).
Deprecated old accessor methods and temporarily add @JsonIgnore to the method to avoid leakage but keep signatures intact.
We're now favoring the generic TypeInformation over trying to resolve the property type via field or PropertyDescriptor as only the former does proper generic type resolution.
Type specialization - i.e. enrichment of a raw type with a current generic context - is now only done if the current type is not yet resolved completely. This allows wildcarded target references to just fall back to the type to specialize, which will then by definition carry more generics information than the one to be specialized.
Revert the merging of a parent type's type variable map and only apply the locally available declared generics in case of parameterized types. Moved that augmentation into ParameterizedTypeInformation.
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
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.
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.
For repository query methods with a dynamic projection parameter, the ResultProcessor is recreated with the type handed to the method. This results in recreation of the ProjectingConverter, which previously recreated a DefaultConversionService instance (for fallback conversions), which is rather expensive due to the reflection lookups checking for the presence of libraries on the classpath.
This is now avoided by using copying methods that reuse the initially created DefaultConversionService.
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).
ObjectInstantiator needs to be declared public as otherwise loading the implementation class fails as it doesn't have access to the (package) private interface in a different classloader.
