We now support configuration of the class loader in SimpleTypeInformationMapper to use a configured class loader instead of falling always back to the default/contextual class loader. In arrangements where the contextual class loader isn't able to provide access to the desired classes (e.g. parallel Streams, general Fork/Join Thread usage) the contextual class loader may not have access to the entity types. By implementing BeanClassLoaderAware, we can now propagate a configured class loader.
Closes#2508
A few further tweaks: ClassTypeInformation now never unwraps the user type to consistently work with the type originally presented in the lookup. That allows us to get rid of the custom equals(…)/hashCode() methods and removes the need to deal with original and user type in the same CTI instance.
The augmented caching of PersistentEntities in AbstractMappingContext now primarily happens in doAddPersistentEntity(…). We still need to implement a cache manipulation for the case that a user type has caused the creation of a PersistentEntity first and we see a lookup for the proxy type later. Before actually processing the TypeInformation we now try to lookup an already existing PersistentEntity for the user type and augment the cache if one was found.
See #2485
Original pull request: #2486.
Remove isProxyTypeInformation from TypeInformation. Use computeIfAbsent to fall back to user type information when attempting to add a entity to the MappingContext.
See #2485
Original pull request: #2486.
This commit makes sure to only create a PersistentEntity for an actual user type. Therefore ClassTypeInformation now considers the given type and not only the user one for both equals and hashcode. This makes sure we can distinguish TypeInformation for a proxy from the one of a user class.
The AbstractMapping context will take care of unpacking proxied types and registering the created entity for both the user as well as the proxy type information.
Prior to this commit build time generated proxy instances would have been able to pollute the context depending on the order they had been served by the initial entity set.
Closes#2485
Original pull request: #2486.
We now look up bean definitions for repositories using BeanFactory.getMergedBeanDefinition(…) to consider parent-child relationships across application contexts.
As we iterate through bean definitions considering ancestors we need to allow parent bean definitions. Previously, we obtained the bean definition from the child context and since the bean was inherited from the parent, the child context cannot provide a bean definition.
Closes#2383
Original pull request: #2384.
FluentQuery allows extending a query specification initially defined by a Example probe or a Querydsl Predicate and fetching the actual result through a functional programming model:
interface PersonRepository extends QuerydslPredicateExecutor<Person> {
<S extends T, R> R findBy(Predicate predicate, Function<FluentQuery.FetchableFluentQuery<S>, R> queryFunction);
}
PersonRepository repo = …;
List<PersonProjection> result = repo.findBy(QPerson.person.name.eq("Walter"), q -> q.sort(Sort.by("lastname")).as(PersonProjection.class).all());
Closes: #2228
Original pull request: #2421.
