The changes for DATACMNS-854 and DATACMNS-912 dropped the support for the simpler redeclaration of generic methods like CrudRepository.save(…) which as of the changes requires to be redeclared like <T extends Foo> T save(T entity). Previously a simple redeclaration like Foo save(Foo entity) was sufficient.
This commit reintroduces the check for a direct match of the parameter types and shortcuts the more detailed check that's necessary in case of type variables being involved.
Related tickets: DATACMNS-854, DATACMNS-912.
Moved the enum declaration to a more appropriate position. Moved the author addition to the part of the codebase that was actually changed. Expanded copyright year.
Moved unit tests to more appropriate position. Added another one to make sure a reference to a boolean property "empty" can still be supported by adding an explicit Is to make sure we detect a simple property reference.
Original pull request: #203.
Simplified type check by using Set as method signature to avoid unnecessary manual array wrapping. Simplification in the test assertions. A bit of Javadoc, corrected imports and author tags.
Original pull request: #200.
To eagerly catch invalid declarations, query methods using pagination had a check applied that the method either returns a Page or List. We've introduced support for alternative collection libraries (Javaslang in particular) and thus the check needs to take these newly supported types into account.
This is now fixed by externalizing the valid types into QueryExecutionConverters and using the ones returned by that to check against.
Original pull request: #200.
The nullable wrapper types now expose whether they're a single value type or a multi value type. This is necessary as Javaslang's Option implements Iterable (something we previously checked for to detect a collection query) and the custom collections potentially being usable within other wrapper types (e.g. Future<Seq<User>>).
Introduced overload for CustomRepositoryImplementationDetector.detectCustomImplementation(…) to take a RepositoryConfiguration to simplify the invocation from the Spring container related client. Further simplification to unify invocations also from the CDI implementation to be done in 2.0.
Expose getExcludeFilter() on RepositoryConfiguration to not have to inspect the configuration source on clients.
Formatting and Javadoc. Missing license headers in newly created types.
Original pull request: #195.
The detection algorithm for custom repository implementations now considers the exclude filters declared in the overall repository setup (XML and annotations).
Original pull request: #195.
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.
Entities without an identifier previously an exception because the IsNewStrategyFactory wasn't able to determine a strategy even if there was no auditing to be applied in the first place.
We now eagerly check for auditability and skip the lookup for an IsNewStrategy completely in case that check returns false.
Related pull request: #189.
Equipped @Persistent, @RepositoryDefinition and our Repository marker interface with @Indexed so that Spring 5's annotation processor will detect types annotated with or extending the aforementioned type for inclusion in the component index.
Related ticket: SPR-11890.
To make sure that event handlers can read the state of the aggregate persisted, we now invoke the call to the repository before publishing the events. That shouldn't make too much of a difference to most listeners as the event usually contains a reference to the aggregate. However, the new model generally aligns with the approach of reporting what *already has happened* better that our previous approach of first publishing the events and then invoking the repository method.
Related tickets: DATACMNS-928.
We now exclude getter methods that are default methods from the consideration which properties of a projection interface are considered input properties in the first place.
Some additional Java 8 polish in DefaultProjectionInformation.
We now manually filter already gathered property names in ReturnedInterface.getInputProperties() as we have to deal with duplications for properties with the same name at different levels of the inheritance hierarchy.
RepositoryFactoryBeanSupport now takes the repository interface as a constructor argument instead of as a setter. This makes sure that the container induced type prediction for factory beans actually wires the interface *before* it calls getObjectType() on the instance. This allows us to remove the extra infrastructure we had in place to predict the bean types and autowiring will just work out of the box.
Adapted infrastructure code accordingly, removed obsolete infrastructure code and adapted test cases accordingly.
The interceptor discovers whether a transaction was running before the call entered the repository proxy and exposes that fact via ….isSurroundingTransactionActive() for donwstream usage.
Related ticket: DATAJPA-1023.
Javaslang's collection and map types can now be used on repository query methods and get adapted similarly to nullable wrapper types (like JDK's Optional). Also made TypeInformation infrastructure aware of the map type so that a value type lookup gets handle correctly.
We now support downcasts (e.g. user.as(QSpecialUser.class).…) expressions in Querydsl web binding. We do so by skipping the introduced intermediate step in the path when calculating the dot path.
Refactored the internals of the binding to now work based on a PathInformation implementation for which either a Querydsl Path or a Spring Data PropertyPath can be used. This allows us to reuse the paths of predefined bindings.
A bit of Lombok cleanup in internal implementations.
Previously a null value was added to the list of associations if it was handed to BasicaPersistentEntity.addAssociation(…). We now drop those null values and log a warning as it usually indicates a MappingContext implementation identifying a property as association but subsequently failing to look it up.
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.
We now publish events for all methods named "save" on the repository. Fundamentally, that's in place to capture calls to CrudRepository.save(Iterable entities), too.
Some minor refactorings to the internal setup of EventPublishingMethodInterceptor. More JavaDoc.
Introduced @DomainEvents usable on a method of an aggregate root. The method will be invoked when the aggregate is passed to a repository to save and its returned value or values will be exposed via an ApplicationEventListener.
Also, the aggregate can expose a method annotated with @AfterDomainEventPublication which will be invoked once all events have been published.
We now try to look up a target class method based on concrete name and parameter type before falling back on the more expensive type matches. This also eliminates the possibility of invalid method matches as described in the ticket.
Oliver Gierke
Michael Cramer
Maciek Opala
Peter Rietzler
Christoph Strobl
Mark Paluch
Jens Schauder
Barak Schuster