We now deploy a custom BeanPostProcessor to customize RequestMappingHandlerAdapter instances by prepending a ProxyingHandlerMethodArgumentResolver (requiring a @ModelAttribute) to the list of resolved HandlerMethodArgumentResolvers to make sure the settings defined in the annotation are applied but the projecting way of data binding is still used.
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.
Path expressions are now evaluated one by one with the first one actually available in the payload being used for value lookup. Also tweaked the default behavior to return null in case of an single, invalid path.
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.
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.
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.
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.
We now hand the Pageable contained in the Page to the code that constructs the self link.
Added toEmptyResource(Page, Class) to force clients to resolve an optional base link before calling the method. Removed deprecated method to append pagination template parameters.
Removed custom JUnit integration as we can just create HidingClassLoader instances in the test and the integration actually causes more code being needed (additional JUnit rule, method level annotations etc.).
Tweaked ShadowingClassLoader to make obvious what has been changed over the Spring Framework variant. Created upstream ticket [0] to ask for the tweaks that would allow us to remove the class again.
Changed SpringDataWebConfigurationImportSelector to be lenient against the ResourceLoader not being available.
Original pull request: #202.
Related ticket: SPR-15439
[0] https://jira.spring.io/browse/SPR-15439
ClassLoaderRule with @ClassLoaderConfiguration allows easy creation FilteringClassLoader. Changed usage pattern of ClassUtils.isPresent(…) in order to ease testing. Copied the ShadowingClassloader from SpringFramework to get a constructor that doesn't shadow anything by default.
Original pull request: #202.
Pageable now exposes a dedicated null-object representing the absence of pagination so that all places that previously handled null values can now rather be more relaxed and assume that a non-null value is given.
Make use of lambdas and method references though out the codebase. Remove no longer required generic type parameters.
Additionally remove unused imports and replace single element list initialization with dedicated singletonList.
Use Assertion overloads taking Supplier for dynamic assertion error messages.
Removed a bit of reflection from ApplicationContext interaction. Some generics tweaks to avoid unnecessary casts and compiler warnings. Static methods where possible. JavaDoc polish in ProjectingJackson2HttpMessageConverter.
Added a test for loading of QuerydslPredicateArgumentResolver, but it fails presumably because EnableSpringDataWebSupport is not in effect.
Renamed SpringDataWebConfigurationUnitTests to SpringDataWebConfigurationIntegrationTests since it is actually an integration test.
Related ticket: DATACMNS-993.
ProxyingHandlerMethodArgumentResolver is now more lenient when it comes to which types to support for proxying. As indicated in the ticket, we've been to aggressive opting in for all interfaces which - depending on the order of converter registrations - caused us interfering with other interface based resolutions (e.g. in Spring Mobile, Security etc.).
We now only aggressively kick in if either the type or parameter is annotated with @ProjectedPayload or the type itself is not a Spring Framework or native Java one. This should leave user defined types still be accepted whereas the types we previously erroneously interfered with should now be ignored.
Both the configuration code looking up Spring Data specific Jackson modules as well as the code detecting whether we have multiple Spring Data modules on the classpath used component scanning. That can have quite significant impact on startup times.
This commit replaces the classpath scanning with the use of SpringFactoriesLoader that now requires modules that want to extend the behavior of Spring Data's web configuration or indicate a repository implementation being present by shipping a file called META-INF/spring.factories. Spring Data relies on the following keys:
- org.springframework.data.web.config.SpringDataJacksonModules - list the Spring configuration classes that will expose additional Jackson modules that are supposed to be registered for Spring Data's Jackson web support
- org.springframework.data.repository.core.support.RepositoryFactorySupport - list the Spring Data repository factory implementation class that implements repository support for your module. The general detection and configuration mechanism for user repositories is not affected by this. Currently Spring Data only uses the pure number of different entries for that key to switch into strict configuration mode in case we find more than one entry.
PageableHandlerMethodArgumentResolver.isFallbackPageable() now correctly guards against the fallback Pageable being null, a situation that's explicitly deemed valid in setFallbackPageable(…).
Changed the implementation of both the JSON Path and XPath based projecting HttpMessageConverters to make sure the cached decisions don't depend on the media type. Reuse the evaluation of the media type in AbstractHttpMessageConverter.
When a recursive decent operator is used in a JSON Path expression there's no way to get out of the array mode again to indicate one is interested in a particular element (e.g. "the first one no matter where in the document") [0]. We now work around this by always letting the parser return lists, so that the mapping library finally kicking in can be equipped with the correct target type to create.
Unfortunately this causes arrays to be double-wrapped for definite paths so that we basically have to adapt the type handed to Jackson in another round to the unwrap the mapping result in turn [1].
[0] https://github.com/jayway/JsonPath/issues/248
[1] https://github.com/jayway/JsonPath/issues/249
Projection types annotated with @ProjectedPayload can now be used as parameters for @RequestBody annotated Spring MVC controller method parameters.
Accessor methods will be translated into JSON path property expressions which can be customized by using the @JsonPath annotation. The methods are allowed to return simple types, nested projection interfaces or complex classes which will will be mapped using a Jackson ObjectMapper.
Introduced a template method to override the creation of a PagedResource to allow subclasses to create a more concrete instance than PagedResource itself.
QueryMethods now expose a ResourceProcessor which is exposes information about the final to be created object types which can either be DTOs containing a persistence constructor (see @PersistenceConstructor) or projection interfaces. The former are analyzed for constructor properties so that store implementations can use that information to create projected queries that return exactly the fields required for that DTO.
Projection interfaces are inspected, their properties are considered input properties and the same projection queries can be issued against the data store. If a projection contains dynamically calculated properties (i.e. it uses SpEL expressions via @Value) the original entities have to be queried and can be projected during post processing.
ProjectionFactory now exposes a more advanced ProjectionInformation that has additional meta information about the projection type. ProxyProjectionFactory now refers to the BeanClassLoader instead of the ResourceLoader.
RepositoryFactory(Bean)Support now also implement BeanFactoryAware to forward the BeanFactory to the SpelAwareProxyProjectionFactory which in turn now gets handed into the QueryLookupStrategy as well as the QueryMethod.
Parameter now knows about a dynamic projection type, which is a query method parameter of type Class bound to a generic method parameter and will be used to determine the projection to be used on a per call basis.
Original pull request: #150.
Switched to new Querydsl 4 artifacts and adapted to changed package names and API changes.
Cleaned up some JavaDoc and APIs in QuerydslBindingsFactory and QuerydslBinderCustomizer.
We now correctly inspect the sort parameter values and also fall back to the default if a single, empty parameter value is given.
Related ticket: DATACMNS-408.
Related pull request: #138.
Moved all Querydsl related bean definitions and customizations to a dedicated configuration class that only gets included if Querydsl is on the classpath.
Extracted a QuerydslActivator for use in Spring Data REST, which uses HateoasAwareSpringDataWebConfiguration via inheritance, not via @EnableSpringDataWebSupport.
Previously, we exposed a QuerydslBindingsFactory as bean method return type which breaks Spring bootstrap even if it's lazy due to its references to Querydsl types.
Related tickets: DATACMNS-669.
QuerydslBindingsFactory creates a completely build up and customized QuerydslBindings instance for a given QuerydslBinderCustomizer type and domain type.
This basically involves creating or obtaining an instance of the customizer with the following algorithm:
1. If an explicit customizer type is given and no BeanFactory is configured, we'll simply instantiate the configured type. This allows simple customizer implementations with a no-arg constructor.
2. If a BeanFactory is configured and a customizer type configured, we're trying to locate a bean of that type in the BeanFactory, falling back to creating an instance of the customizer through the BeanFactory if no existing bean definition can be found. This allows unique customizer bean definitions or complex prototype scoped customizer beans created on the fly.
3. If no customizer type is configured, we check whether the the repository of the domain type implements QuerydslBinderCustomizer and use it if so.
The extraction of that functionality allows that algorithm being used by Spring Data REST, although only step 3 is currently used there as no explicit customizer can currently be configured with Spring Data REST.
