ClassLoaderRule with @ClassLoaderConfiguration allows easy creation FilteringClassLoader. Changed usage pattern of ClassUtils.isPresent(…) in order to ease testing. Copied the ShadowingClassloader from SpringFramework to get a constructor that doesn't shadow anything by default.
Original pull request: #202.
The changes for DATACMNS-854 and DATACMNS-912 dropped the support for the simpler redeclaration of generic methods like CrudRepository.save(…) which as of the changes requires to be redeclared like <T extends Foo> T save(T entity). Previously a simple redeclaration like Foo save(Foo entity) was sufficient.
This commit reintroduces the check for a direct match of the parameter types and shortcuts the more detailed check that's necessary in case of type variables being involved.
Related tickets: DATACMNS-854, DATACMNS-912.
Introduced overload for CustomRepositoryImplementationDetector.detectCustomImplementation(…) to take a RepositoryConfiguration to simplify the invocation from the Spring container related client. Further simplification to unify invocations also from the CDI implementation to be done in 2.0.
Expose getExcludeFilter() on RepositoryConfiguration to not have to inspect the configuration source on clients.
Formatting and Javadoc. Missing license headers in newly created types.
Original pull request: #195.
The detection algorithm for custom repository implementations now considers the exclude filters declared in the overall repository setup (XML and annotations).
Original pull request: #195.
Use simple if manually throwing the IllegalArgumentException instead of an Assert. Should be replaced with an Assert accepting Supplier when moving to Spring 5 and Java 8.
Original pull request: #198.
ProxyingHandlerMethodArgumentResolver is now more lenient when it comes to which types to support for proxying. As indicated in the ticket, we've been to aggressive opting in for all interfaces which - depending on the order of converter registrations - caused us interfering with other interface based resolutions (e.g. in Spring Mobile, Security etc.).
We now only aggressively kick in if either the type is not a Spring Framework or native Java one. This should leave user defined types still be accepted whereas the types we previously erroneously interfered with should now be ignored.
Entities without an identifier previously an exception because the IsNewStrategyFactory wasn't able to determine a strategy even if there was no auditing to be applied in the first place.
We now eagerly check for auditability and skip the lookup for an IsNewStrategy completely in case that check returns false.
Related pull request: #189.
We now exclude getter methods that are default methods from the consideration which properties of a projection interface are considered input properties in the first place.
Unfortunately no tests for this one as we can't declare default methods in our codebase requiring JDK 6 compatibility.
We now manually filter already gathered property names in ReturnedInterface.getInputProperties() as we have to deal with duplications for properties with the same name at different levels of the inheritance hierarchy.
RepositoryFactoryBeanSupport now declares both a default constructor as well as one taking the repository interface as argument like we're going to progress in Ingalls. This allows implementations to tweak their Hopper compatible extensions of the class to also declare both constructors. That causes them to stay compatible with Hopper (which will use the setter) but also run on Ingalls which will use constructor injection.
Previously a null value was added to the list of associations if it was handed to BasicaPersistentEntity.addAssociation(…). We now drop those null values and log a warning as it usually indicates a MappingContext implementation identifying a property as association but subsequently failing to look it up.
We now try to look up a target class method based on concrete name and parameter type before falling back on the more expensive type matches. This also eliminates the possibility of invalid method matches as described in the ticket.
We now no longer attempt query creation for static methods declared on a repository interface. This allows static method usage inside of repository interfaces.
interface PersonRepository extends CrudRepository<Person, String> {
static String createId() {
// …
}
default Person findPerson() {
return findOne(createId());
}
}
PageableHandlerMethodArgumentResolver.isFallbackPageable() now correctly guards against the fallback Pageable being null, a situation that's explicitly deemed valid in setFallbackPageable(…).
This commit changes some ArrayList initializations to use an initial capacity and avoids the unnecessary fetch of the return type of a method in Parameter.isDynamicProjectionParameter().
Original pull request: #180.
Jens Schauder
Oliver Gierke
Peter Rietzler
Christoph Strobl
Mark Paluch
Christoph Dreis