We now synchronize the (seldom) writes to the isPropertyParameterCache HashMap in PreferredConstructor via a ReadWriteLock. We could as well have used a ConcurrentHashMap here without the need for manual locking but this would potentially waste memory for a mostly read-only data structure. We also anticipate potential multiple writes for the same property.
Original pull request: #86.
Parameters erroneously rejected @Param annotated query method parameters that were preceded by a non-bindable type (like Pageable or Sort) as it checked for a 0 index of the parameter. We now manually keep an index in the check itself and have removed the Parameter.isFirst() method as it's not used anywhere else.
We're now using the newly introduced method on ControllerLinkBuilderFactory that takes both a type and a method to forward the method the invocation is happening on independently from the method being invoked.
The property "location" should actually be "locations" since this attribute is read by org.springframework.data.repository.config.ResourceReaderRepositoryPopulatorBeanDefinitionParser.doParse(Element, BeanDefinitionBuilder).
The equals(…) and hashCode() methods of TypeVariableTypeInformation previously tried to evaluate the unresolved context of the type variable. This can cause issues in recursive type definitions as set up in the according test case. We now implement the methods based on the resolved type to makes sure we break the recursive lookup of PersistentEntity instances in AbstractMappingContext.
The erroneous lookup was actually caused by unresolved base types being added to the mapping context within the JPA project as the JPA meta-model also returns those types as managed types.
Related pull request: #84.
We now explicitly discuss the case of referring to properties with underscores (e.g. first_name) in repository query methods.
Added missing language declaration for a code block.
We now also reflectively check for the presence of DefaultParameterNameDiscoverer. This allows the usage of the new reflection methods introduced in Java 8 if the user code is running on Spring 4.
Changed the name of the constant for the ParameterNameDiscoverer in Parameters to meet conventions for constants.
If a configuration class resides in the default package and no base package is defined in the @Enable…Repositories annotation we previously failed in extracting the package from the class name (as there is none).
We now use Spring's ClassUtils that correctly handles this case and returns an empty String for the default package.
Spring 4's GenericTypeResolver returns null when trying to resolve type arguments for types that do not fully resolve the generic types.
Related issues: SPR-11763.
Version parsing failed when given version contained non-numeric parts (like 2.0.0-rc1). We now strip everything after the first non numeric part to create a logical version equivalent of the source String.
Original pull request: #81.
Added a constructor to RepositoryConfigurationDelegate that takes an additional Environment instance to make sure we can equip ClasspathScanningCandidateComponentProviders with Environments to make sure they only find components matching the environment.
Retain the old constructor by defaulting to the Environment the ResourceLoader potentially contains or even a StandardEnvironment in worse cases. This is primarily to not break existing clients. Those should be upgraded to use the new constructor, of course.
Needed to add an additional guard in BeanDefinitionRegistrarSupport as Spring 3.2.8 fails to invoke EnvironmentAware (filed SPR-11744 for that). This should be removed once we upgrade to Spring 3.2.9.
Related pull request: #80.
Related tickets: DATACMNS-493, DATACMNS-494, SPR-11744.
Previously, ParameterizedTypeInformation.hashCode() had been inconsistent to equals in case of a fully resolved parameterized type. This is now fixed by not including the parent reference in case a parameterized type is resolved completely.
Also, TypeDiscoverer.getActualType() does not return the component type for non-collection/non-maps anymore to make sure we don't accidentally unwrap parameterized types.
Changed the algorithm for nested PersistentEntity detection to only use PersistentProperty.getPersistentEntityTypes(…) and make sure we return unwrap Maps and Collections inside the method correctly.
We now explicitly check for the configured default being null and subsequently return that value if we don't have both the page and the size parameter configured.
Update pom.xml to use Spring Data Build parent in 1.3.1.RELEASE as well as the release repository. Update changelog to reflect recent changes / releases. Update notice. Update links in readme to point to spring.io.
Original Pull Request: #74.
We now actively check that the a method in a Spring class we rely on to be public actually is public and throw an exception pointing to the offending JAR in an exception that's thrown otherwise.
Removed the rejecting check for collections and maps and solely rely on the evaluation of the actual type for the ….isEntity() decision in AbstractPersistentProperty. This will cause collection and map properties also being inspected for persistent types as soon as the owner type gets added to the mapping context.
Previously we directly threw a MappingException in MappingContext.getPersistentEntity(TypeInformation) when the MappingContext was in strict mode and we were given a TypeInformation for which we didn't have a PersistentEntity already.
We now first check whether we should actually create a PersistentEntity for the given TypeInformation if no PersistentEntity is available, before throwing a MappingException - if we should not then we simply return null (e.g. for simple types like Integer or Double).
Original pull requests: #66, #71.
Added array checks to AbstractRepositoryMetadata.getReturnedDomainClass() to detect array component types. QueryMethod now considers methods returning arrays to be collection query methods.
Updated links and vendor-information in readme. Updated author information. Fixed some typos, added ids to sections updated examples and descriptions. Added and referenced description of repository populator namespace element.
Original pull request: #65.
If a Converter handed into DefaultPersistentPropertyPath.toDotPath(…) returns null or an empty string for a mapped property name, that value is skipped during path construction.
We now skip bridge methods for query method processing in order to circumvent the changed behavior of Class#getMethods() in Java 8 (when the code was compiled with target byte code level 1.8). On Java 8 this results in bridge methods being found and inspected for query method annotations. Since we currently cannot analyze generic return types of bridge methods this results in NullPointerExceptions being thrown at a later stage in AbstractRepositoryMetadata#getReturnedDomainClass(…).
Original pull request: #64.
Related issue: DATAJPA-465.
Previously the map value type resolving algorithm checked the value type to be of type Map again to shortcut the resolution. We now weakened this to an assignment check and eagerly resolve the generic type if its bound on exactly that level already. If no concrete type argument can be found, we fall back to the general generics resolution mechanism.
The changes in 899cf25 causes Repositories not finding any repository instances in case the lookup of beans by type for RepositoryFactoryInformation if the initialization causes as cyclic reference. Even worse, we might run into cases in which the attempt to access the beans by type causes transitive object creation which results in a successful lookup on a second attempt.
This is effectively caused by the catch-block in DefaultListableBeanFactory.getBeansOfType(…) which registers the suppressed exception as the method is used for lookup the beans for injection points with Lists and Maps.
We now explicitly look for bean names first and access the bean by name afterwards, which guarantees the exception to be thrown if it occurs. This will reveal the underlying issue and let user potentially deal with it. It's generally recommended to refer to Repositories in a very lazy fashion (using Provider<T>, ObjectFactory<T> or @Lazy on the injection point as of Spring 4) to avoid creating circular dependencies through by-type-lookups.
