We now throw InvalidPersistentPropertyPath during property path resolution if an intermediate path segment cannot resolve an entity to resolve the next segment. This can be caused when a non-entity typed property (e.g. List<Object>) is used within the property path and the path resolution attempts to resolve a property path on the non-entity typed property. Previously, resolution failed with NullPointerException.
Introduced ProxyUtils.getUserClass(…) that by default is basically a facade for Spring's ClassUtils.getUserClass(…) but allows the registration of ProxyDetector implementations via Spring's SpringFactoriesLoader mechanism.
Moved all existing usages of ClassUtils.getUserClass(…) to ProxyUtils.
I added a cover page for the epub output, now that the Spring data reference guides will have epub output (through a commit against spring-data-build).
Original pull request: #290.
We now explicitly disable entity expansion in the DocumentBuilderFactory used by XMLBeam.
Introduced constructor in XmlBeamHttpMessageConverter to allow dedicated configuration of an XBProjector instance in case the defaults need tweaking and augmented the web configuration setup to automatically pick up a custom XmlBeamHttpMessageConverter bean instead of our own default if present.
We now load TransactionalProxy through the configured class loader for a consistent class loader usage. Loading types reflectively through the same class loader prevents visibility issues. Previously, we did not specify any class loader which defaults to the Thread's ClassLoader and which can be a different one than the configured class loader. This can cause visibility issues when implementing proxy classes as the proxy factory checks for visibilit of the particularly implemented interfaces.
After considering JSR-310 types to be simple we map these types primarily to java.util.Date as the majority of stores does not natively support JSR-310 types. Converters referencing JSR-310 types are now properly annotated with Reading/WritingConverter annotations to distinguish between reading and writing intents.
Othwerise, converters between JSR-310/java.util types and Joda/ThreeTenBackport to JSR-310 types interfere with conversion as regular java.util.Date types would convert to e.g. LocalDateTime.
To prevent repeated failing calls to ClassUtils.forName(…) we now also cache the failed attempt and simply eagerly return null as subsequent similar attempts to resolve a class are going to fail anyway.
Original pull request: #286.
To prevent repeated failing calls to ClassUtils.forName(…) we now also cache the failed attempt and simply eagerly return null as subsequent similar attempts to resolve a class are going to fail anyway.
Previously a custom Iterable implementation would've caused QueryMethod.isCollectionQuery() to return true. We now solely rely on TypeInformation.isCollectionLike() (which checks for exact Iterable, Collection assignability and arrays) after handling potential wrapper types.
Instead of a simple check for assignability from Iterable, we now properly use TypeInformation.isCollectionLike(), which checks for Iterable equality or assignability of collections or arrays as well as an explicit check for Slice as that is needed to properly unwrap Page instances and Slices themselves. That prevents custom domain types implementing Iterable from being unwrapped into their element types.
Oliver Gierke
Mark Paluch
Christoph Strobl
Jay Bryant
Chengyuan Zhao
Robert Winkler