We now create a copy of the keys before iterating over them in Repositories.getRepoInforFor(…) to make sure other threads can safely trigger lookupRepositoryFactoryInformationFor(…) which potentially alters the repositories instance variable. So far we haven't guarded against this scenario which caused a ConcurrentModificationException.
The configuration entry points (RepositoryBeanDefinitionParser and RepositoryBeanDefinitionRegistrar) now hand the Environment they're running in forward into the infrastructure scanning for repositories. Thus it will correctly find or not find repository interfaces based on which profiles are activated or not.
Changed getPersistentEntity(PersistentProperty<?>) to return the actual type of the persistent property in order to deal with collection and map types transparently.
Original pull request: #31.
Reverted from ConcurrentHashMap to plain HashMap where concurrency wasn't an issue and profiling showed performance hotspots. Introduced caches for ParameterizedTypeInformation.getComponentType() and the resolved raw type in TypeDiscoverer.
BasicPersistentEntity now only caches the most concrete property for a by-name lookup to mimic the behavior that was implemented in getPersistentProperty(String name). This is to prevent shadowed properties of superclasses leaking into the by-name lookups.
Improved AbstractPersistentProperty.toString() to rather render the concrete field it is backed by.
Added caching to DefaultTypeMapper, SimpleTypeInformationMapper, BasicPersistentEntity and PreferredConstructor as these seem to be performance hotspots on the reading side of object conversion.
So far, the PageImpl class returned 0 as total number of pages if set up from a plain List. This returns 1 now (as it should be). We've also adapted the hasNextPage() implementation to correctly calculate whether a next page is available.
This causes the configured persistent entities being added to the context on its initialization instead of a delayed initialization on ApplicationContext refreshed event.
This change was introduced to ease the upgrade of STS to recent Spring Data Commons versions, originally introduced to enable Spring 4 compatibility (see DATACMNS-324).
So far we threw exceptions in case we find the same exception on getters *and* setters. We now allow this scenario in case the annotations are semantically equivalent.
We now don't try to eagerly lookup the beans Repositories shall capture in the constructor anymore but leniently look them up on the first request. Update tests for classes using Repositories alongside.
So far the property lookup of a nested property path (e.g. "foo.bar") failed in cases the head property was not cached already. We now recursively resolve the type information even for an unpopulated cache.
Previously, the RepositoryBeanDefinitionBuilder did not forward the repository configuration's source instance into the built BeanDefinitions. This is now fixed to enable STS track the origin of the BeanDefinition back to the configuration source (an @Enable-annotation or an XML namespace element).
ReflectionEntityInstantiator now actually throws the wrapped exception created in the catch block handling BeanInstantiationExceptions.
Pull request: #25.
AnnotationBasedPersistentProperty now caches direct annotations on construction but still tries to lookup an annotation as meta-annotation if not found in cache on later requests. Extended try/catch block in AbstractMappingContext.addPersistentEntity(…) to invalidate cache on exceptions during property creation as well.
