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.
We now eagerly populate the repository factory information in Repositories to provide a read only view on the discovered repository information. Previously lookup operations could also change some maps that held information about the until then discovered repository meta data which could lead to ConcurrentModifcationExceptions in multi-threaded environments. Since we don't allow any modification after construction this won't happen anymore.
We also cache the computed RepositoryMetadata in RepositoryFactoryBeanSupport.
Original pull request: #63.
In case of an unresolvable generic parameter in TypeDiscoverer's getTypeArgument(…) we check for a generic super type for the given bound and fall back to Object in case we find a parameterized type.
Turned the static cache of RepositoryInformations in RepositoryFactorySupport into a non-static one to avoid the instance from potentially surviving redeployments in web app scenarios.
We're now replacing the sort parameter for the URI to be created instead of simply appending them to the source URI to prevent previously applied sort parameters to be taken forward.
The PageableHandlerMethodArgumentResolver and SortHandlerMethodArgumentResolver now transparently ignore invalid values provided for page number, size and sort. We fall back to ignore the invalid values (for sort) and fall back to the defaults where appropriate (page number and size).
Used and adapted test cases from pull request #48.
PageRequest now actively prevents page sizes less than one. PageableHandlerMethodArgumentResolver falls back to default page size if it detects a page size less than one. It also rejects invalid default configuration using @PageableDefault.
We now resolve the domain and id-types eagerly within the constructor of AbstractRepositoryMetadata implementations to prevent a RepositoryMetadata instance to be created in an invalid state. Pulled-up repositoryInterface property to AbstractRepositoryMetadata.
Original pull request: #58.
The detection of CRUD methods in DefaultCrudMethods is now carried out in a more robust and predictable fashion. The exact algorithm is described in the JavaDoc.
Original pull request: #55.
Instead of creating a new DefaultRepositoryInformation for each call to getRepositoryInformation(…) we now actively cache the created instances per repository type and custom implementation class.
To prevent ConcurrentModificationExceptions when iterating over PersistentEntities while further entity types are potentially added to the MappingContext we now return a immutable defensive copy of the current entity set.
Based on the discussion in SPR-11004 [0], the declaration of the PagedResourcesAssembler in HateoasAwareSpringDataWebConfiguration will not result in it being autowired using Spring 4.0 in certain circumstances. This change loosens the declaration so that it can be autowired into declarations that have specific generics declarations.
Original pull request: #51.
[1]: https://jira.springsource.org/browse/SPR-11004
We're now rejecting invalid constructor arguments handed to ClassTypeInformation, Part, PartTree and PropertyPath. Beyond that we skip the creation of a Part for an empty path segment, so that you don't end up with an invalid Part instance for a findAllByOrderByFooAsc.
When matching the save(Iterable<T>) method of CrudRepository for an entity implementing Iterable we accidentally determined CrudRepository.save(T) as target method if the entity type under consideration implements Iterable.
We now explicitly check for the parameter type not being Iterable when matching the domain type generics in matchesGenericType(…).
In Repositories.getCrudInvoker(…) we now throw an IllegalArgumentException if we cannot find an appropriate repository for the given domain class. Previously it just blew up with a NullPointerException without a clear error message.
Original pull request: #46.
When looking up the RepositoryFactoryInformation for a domain type we now make sure we look up the user type to not accidentally try to do so for a persistence provider generated proxy class for the original type. This prevents us from not finding PersistentEntity instances, Repository- or EntityInformation accidentally.
Added appropriate test to PartTreeUnitTests to check whether the regular expression in PartTree doesn't accidentally finds keywords in property expressions.
Modified the regex for prefix_template and keyword_template in PartTree in order to support arbitrary unicode characters. Before that change we didn't support unicode correctly since we assumed that a character would have a lower and upper case representation which is often not the case, e.g. in chinese.
Original pull request: #41.
Added a test case to show that PagedResourcesAssembler correctly renders 1-indexed, empty pages after upgrading to Spring HATEOAS 0.8.0.BUILD-SNAPSHOT.
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.
Extracted the implementation of UriComponentsContributor from PageableHandlerMethoArgumentResolver and SortHandlerMethodArgumentResolver into dedicated subclasses so that we can really make Spring HATEOAS an optional dependency.
The integration tests are now guarded with an assumption to run on Spring 3.2 as Spring 3.1 has issues with JavaConfig and configuration method overrides. We've upgraded to Spring Data Build 1.2 snapshots so that the tests can be run with -Pspring32. This effectively means that the Spring Data Web support can only be used with a current Spring 3.2. Added a note on that in the reference docs and JavaDoc of @EnableSpringDataWebSupport.
Original pull request: #39.
Changed implementation in AbstractEntityInformation quite a bit to not need the non-final fields and a protected callback method. Cleaned up test cases to really test the new behavior, not the artificially introduced test helper class.
Original pull request: #37.
AbstractEntityInformation now detects primitive id types and adapts the isNew state according to the Java Language Specification §4.12.5. Supported are primitive Numbers and the entity is considered new if the value of the primitive field is zero.
Original pull request: #37.
Let both RepositoryFactorySupport and RepositoryFactoryBeanSupport implement BeanClassLoaderAware to pick up the ClassLoader used by the container. The latter class forwards the configured instance into the factory it creates.
PageableHandlerMethodArgumentResolver and SortHandlerMethodArgumentResolver now consistently use set*ParameterName(…) and setQualifierDelimiter(…) for configuration.
Added some more unit tests to verify invalid configuration get rejected.
We now leniently try to lookup DefaultParameterNameDiscoverer and create an instance of it to make use of Spring 4's improved parameter name capabilities on Java 8. We fall back on a LocalVariableTableParameterNameDiscoverer if on Spring versions prior to 4.
We're not manually converting the DateTime instance into the user field type but delegate to a ConversionService instance. This will allow us to automatically adhere to enhancements in conversion capabilities to the DefaultConversionService.
SortHandlerMethodArgumentResolver now has a setFallbackSort(…) to be able to configure the Sort instance to be used if nothing can be resolved from the request and sort default is configured on the controller method.
Renamed name of getDefaults(…) method in SortHandlerMethodArgumentResolver to getDefaultFromAnnotationOrFallback(…) and refactored implementation to be more understandable.
Original pull request: #36
Parameters is now a class explicitly designed for extension using generics. We provide a new DefaultParameters which is essentially a drop in replacement for former Parameters as it exposes individual Parameter instances.
Modules that previously extended Parameters will now have to implement the abstract factory methods exposed to create concrete - and potentially customized - Parameter instances.
Oliver Gierke
Martin Baumgartner
Thomas Darimont
Ben Hale
Nick Williams