Added some JavaDoc where missing. Better variable names and slightly parameter ordering changes. Formatting in the unit tests and reference to the original ticket.
Original pull request: #98.
Introduced BytecodeGeneratingEntityInstantiator which dynamically generates classes to speed up the dynamic instantiation of objects. Since we cannot support every use case with byte code generation we gracefully fallback to the ReflectiveEntityInstantiator.
BytecodeGeneratingEntityInstantiator has support for unboxing of constructor parameters and more robust handling for cases where we cannot generate a custom ObjectInstantiator.
Original pull request: #98.
Clarified return values if predicates don't match or return multiple results (for the findOne(…) method). Copied summary to the @return tag.
Original pull request: #96.
We now require a JDK to build Spring Data Commons as using the custom Optional type from the Spring Data Build project as it causes the tests to break as Spring 4.1 snapshots load the Optional type to check for it's ability on the classpath which the JVM rejects.
The detection of the custom implementation has now been moved into the Bean base class to avoid calls to BeanManager.getBeans(…) (which are necessary to pick up the configuration class defining postfixes and the like) happen to early in the CDI container lifecycle.
Related ticket: DATACMNS-557.
Previously we only allowed to sort by QueryDsl path expressions. With this change we now also support ordering by operator expressions, e.g. yearMonth() on a date property.
Original pull request: #94.
Added missing closing backtick in auditing.adoc. Added copyright line to index.adoc and switched to relative level offsets. Use two blank lines at the end of each file consistently. Extracted preface document and added project metadata.
The type detection for entity candidates of PersistentProperty instances now consistently handles collection types even if they're used als collection or map values.
Annotations used on both fields and accessors are now only rejected if they're Spring Data annotations (i.e. from the org.springframework.data namespace) and the configurations of these annotations differ.
Renamed CdiRepositoryConfigurationSource to CdiRepositoryConfiguration. Turned anonymous inner default implementation into dedicated enum to avoid repeated instantiation.
Changed the CdiRepositoryBean to rather take a Bean instance of the custom implementation instead of the resolved object to make sure both instances (the custom implementation and the repository proxy) are instantiated at the same time.
Fixed imports. Some early returns to avoid unnecessary nesting.
Adapted architecture description to allow CDI module accessing the configuration module.
Related pull request: #92.
The CDI extension now discovers a custom implementation class similarly to the detection when using Spring Data in a Spring container. Extracted the custom implementation detection for re-use. The CDI extension discovers the potentially available bean and hands it to the CdiRepositoryBean for further usage.
Implementations should implement the extended variant of the create(…) method we introduce with this commit to be able to forward the resolved custom implementation bean.
Original pull request: #92.
We now apply a stricter repository interface selection if we detect multiple Spring Data modules to be in the classpath to avoid the repository scanning accidentally overriding each others definitions or even picking up interfaces they weren't intended to manage.
The detection is based on a type scan in dedicated base package where subtypes of RepositoryFactorySupport usually reside. If more than one type is found, we activate strict scanning.
The strict check is actually implemented in RepositoryConfigurationExtensionSupport to be accessible for store implementations. By default we try to load the repository candidate interface and inspect the managed domain types for a collection of annotations (see RepositoryConfigurationExtensionSupport.getIdentifyingAnnotations()). Implementors still have the chance to customize the behavior by overriding isStrictRepositoryCandidate(…).
We also introduced a getModuleName() to be able to create better logging output in terms of repository registration. Moved registration of RepositoryConfigurationExtension as Spring bean into the base types for XML and annotation configuration support to make sure they only kick in if explicit configuration is used.
PropertyPath now exposes the complete property named the resolution failed for in case it can't resolve a source String. It will expose the part of the Path from the deepest successful resolution result.
Changed the resolution algorithm to use a List instead of a Stack and a fresh instance of the former so that the nested recursion steps keep track of the correct resolution depths.
RepositoryConfigurationDelegate now registers the store-specific RepositoryConfigurationExtension as lazy-init BeanDefinition so that other parties can detect that definition.
We're now firing the component registration event manually in RepositoryBeanDefinitionParser as ParserContext.registerBeanComponent(…) registers the given BeanComponentDefinition with the registry. As we do that manually before this previously resulted in the BeanDefinition overriding the very same one and container warnings in turn.
Refactored the implementation of the dynamic lookup of properties and functions on EvaluationContextExtensions. All the reflective lookup logic has moved into an EvaluationContextExtensionAdapter.
We now also distinguish between the meta-information that can be looked up once and cached (so that we avoid reflection overhead for subsequent context creations).
Related pull request: spring-projects/spring-data-jpa#101
Related ticket: DATAJPA-564
Changed SPI to expose a Function type rather than plain methods as well as an arbitrary root object.
Related pull request: spring-projects/spring-data-jpa#101
Related ticket: DATAJPA-564
Collapsed variable gathering methods into one, make sure we expose all values (also null ones). Renamed unit test for ExtensionAwareEvaluationContextProvider according to the class name. Some further cleanups in the test case.
Related pull request: spring-projects/spring-data-jpa#101
Related ticket: DATAJPA-564
Oliver Gierke
Thomas Darimont
Spring Buildmaster
Mark Paluch
Oliver Gierke
Thomas Darimont