As indicated by our recent Spring Integration test failure, autowiring attempts after context closing did not fail before. After the introduction of the separately managed manualSingletonNames set, the algorithm could run into a situation where a singleton name is still in the manualSingletonNames set but not in the singletonObjects map anymore. As a remedy, destroySingletons needs to explicitly clear the manualSingletonNames set in order to remove references to non-disposable singleton beans as well (which are otherwise left in the set since individual destroySingleton calls only come in for disposable beans with destroy methods).
Issue: SPR-12404
This commit adds an explicit support for String array for value
resolution. <util:properties> switches the 'locations' property to a
String array in 662d8aa and this broke expression evaluation.
Issue: SPR-12391
Snake YAML allows for duplicate keys in map nodes. See
https://code.google.com/p/snakeyaml/issues/detail?id=199
This commit uses a dedicated Constructor extension that explicitly
checks for such duplicate keys.
Issue: SPR-12318
This commit fixes a potential NPE when determining the priority of a
bean instance in case multiple candidates exist and no bean was marked
as @Primary
Issue: SPR-12024
This commit adds the missing 4.1 XSDs for the following components:
* spring-aop
* spring-context
* spring-jee
* spring-lang
* spring-tx
* spring-util
These are strictly identical to the definition of the 4.0 XSDs.
Issue: SPR-11990
Commit 5fe8f52 introduced a support for @Priority as an alternative to
@Primary but it broke the semantic of the priority value. This commit
fixes this inconsistency.
As for @Order, the lowest value means the highest priority so if
several beans are candidates for injection, the one having the lowest
value will be used.
Issue: SPR-10548
This commit adds a nested path support for DirectFieldAccessor that is
similar to what BeanWrapper provides. It is now possible to use
expressions such as "person.address.city.name" to access the name of
the city that a given person lives in using fields to traverse the
graph.
DirectFieldAccessor also now supports an auto-grow option to create
a default instance for a "null" intermediate path. This option is
false by default and leads to a NullValueInNestedPathException in such
a case.
This commit also harmonizes part of the tests suite so that core tests
are shared between BeanWrapperImpl and DirectFieldAccessor.
Note that map and list access is not implemented as part of this
commit.
Issue: SPR-9705
After this change, java.util.Optional is supported with @RequestParam,
@RequestHeader, and @MatrixVariable arguments in Java 8. When Optional
is used the required flag is effectively ignored.
Issue: SPR-11829
Includes support for arbitrary deep nesting levels in DependencyDescriptor's getDependencyType() and MethodParameter's getNestedParameterType().
Issue: SPR-11833
This commit introduces OrderProvider and OrderProviderComparator, two
interfaces designed to externalize how a collection of element is sorted
according to their order value.
FactoryAwareOrderProvider is an OrderProvider implementation that knows
about the objects to order and the corresponding BeanFactory instance.
This allows to retrieve additional metadata about the actual instances
to sort, such as its factory method.
A @Bean method can now holds an additional @Order to define the order
value that this bean should have when injected as part of a collection
or array.
Issue: SPR-11310
This commit migrates the YAML support available in Spring Boot to
the core framework. YAML documents can be loaded either as a
properties object or as a map.
Issue: SPR-9897
Animal sniffer provides tools to assist verifying that classes
compiled with a newer JDK are compatible with an older JDK.
This integratesthe latest version of the tool (1.11) that
permits the use of custom annotations. Added @UsesJava7,
@UsesJava8 and @UsesSunHttpServer and annotated the few places
where we rely on a specific environment.
The verification process can be invoked by running the 'sniff'
task.
Issue: SPR-11604
polishing
Prior to this commit, an exception thrown by an @Async void method
was not further processed as there is no way to transmit that
exception to the caller.
The AsyncUncaughtExceptionHandler is a new strategy interface that
can be implemented to handle unexpected exception thrown during the
invocation of such asynchronous method.
The handler can be specified using either the XML namespace or by
implementing the AsyncConfigurer interface with the EnableAsync
annotation.
Issue: SPR-8995
This commit rationalizes the use of @Order so that the standard
@Priority annotation can be used instead. The handling of both
annotations are now defined in OrderUtils.
This also updates the link to the JavaEE API so that we refer to
JavaEE7 instead of JavaEE6.
Issue: SPR-11639
This commit adds support for @Priority to filter multiple candidates
for autowiring. When multiple candidates are available for a given
bean, the bean annotated with @Primary is used. If none exists, the
one with the higher value for the @Priority annotation is used. If
two beans have the same priority a NoUniqueBeanDefinitionException
is thrown, just as if two beans are annotated with @Primary.
The underlying code for #getBean and #resolveDependency has been
merged as this feature is available for both dependency injection
and bean lookup by type.
Issue: SPR-10548
Added tests checking the behaviour of autowiring by type when the @Primary
annotation is present on the class. Fixed also some inconsistencies in the
code.
Prior to this commit, the codebase was using a mix of log4j.xml
and log4j.properties for test-related logging configuration. This
can be an issue as log4j takes the xml variant first when looking
for a default bootstrap configuration.
In practice, some modules declaring the properties variant were
taking the xml variant configuration from another module.
The general structure of the configuration has also been
harmonized to provide a standard console output as well as an
easy way to enable trace logs for the current module.
Restored original singleton-only adaptInnerBeanName behavior, avoiding endless unique name calculation for every single prototype instance. Non-named inner BeanDefinition objects now suffixed with an identity hex code analogous to non-named XML bean definitions, largely avoiding naming collisions to begin with. After SPR-11246, post-processors can deal with unstable classes per bean name, so occasional collisions aren't a hard problem anymore.
Issue: SPR-11545
This commit continues the work for fixing memory leaks resulting from
CGLIB subclass generation for beans relying on method injection.
- Set proxy callbacks on the CGLIB Factory (i.e., the instance) instead
of in the generated subclass (i.e., via the Enhancer).
- Convert private inner classes in CglibSubclassingInstantiationStrategy
to private static classes in order to avoid unnecessary coupling to
classes generated using CGLIB.
- Tidy up XmlBeanFactoryTests.
- Update logic in serializableMethodReplacerAndSuperclass() so that it
finally aligns with the decision made for SPR-356.
Issue: SPR-10785, SPR-356
Prior to this commit, the inclusion of the 'overloaded' flag in the
implementations of equals() and hashCode() in MethodOverride could lead
to adverse effects in the outcome of equals() in AbstractBeanDefinition.
For example, given two bean definitions A and B that represent the
exact same bean definition metadata for a bean that relies on method
injection, if A has been validated and B has not, then A.equals(B) will
potentially return false, which is not acceptable behavior.
This commit addresses this issue by removing the 'overloaded' flag from
the implementations of equals() and hashCode() for MethodOverride.
Issue: SPR-11420
According to the JDK's documentation and changelog, the Introspector itself safely handles weak references as of JDK 6 update 21 (which is what we require for Spring 4.0).
Issue: SPR-11356
This in particular allows for specifying "spring.getenv.ignore" and "spring.beaninfo.ignore" in a local way within the application, in case that JVM-level system properties are locked.
Issue: SPR-9014
Issue: SPR-11297
This allows us to avoid early initialization of footprint-heavy ConcurrentHashMaps, and reuses the existing postProcessingLock which will typically be active already when registerExternallyManaged* calls come in from the bean factory's post-processing phase.
Issue: SPR-11343
Specifically, read and write methods are allowed to express property types with superclass/subclass relationships in both directions now.
Issue: SPR-11139
Specifically, if the current factory has Qualifier/ContextAnnotationAutowireCandidateResolver set up, it is important to pass it on to ancestor factories to get consistent qualifier matching results.
Issue: SPR-10966
Our per-bean caching in AutowiredAnnotationBeanPostProcessor and co relies on unique bean names, so this change fixes potential cache mismatch problems occuring there.
Issue: SPR-11131
Attempt to improve performance by caching TypeDescriptors against bean
PropertyDescriptors in CachedIntrospectionResults.
This change is an attempt to fix the failing performance test case
`testPrototypeCreationWithOverriddenResourcePropertiesIsFastEnough` in
`AnnotationProcessorPerformanceTests`.
Apply consistent styling to new classes introduced in Spring 4.0.
- Javadoc line wrapping, whitespace and formatting
- General code whitespace
- Consistent Assert.notNull messages
Fix a variety of typos throughout the project, primarily in
comments (javadoc or otherwise) but also in a handful of log messages
and a couple exception messages.
ISSUE: SPR-11123
Fix remaining Java compiler warnings, mainly around missing
generics or deprecated code.
Also add the `-Werror` compiler option to ensure that any future
warnings will fail the build.
Issue: SPR-11064
Since @Bean methods are never used with externally specified constructor argument values but rather just with autowiring, the non-lenient constructor resolution mode is appropriate in case of an overloaded @Bean method, not performing any type difference weight checks. This change includes a refinement of Spring's existing non-lenient constructor resolution (which needs to be explicitly turned on and is therefore not well tested), narrowing the conditions for the ambiguity check (only in case of the same number of arguments and not for overridden methods).
Issue: SPR-10988
XML-defined arguments values are initially turned into TypedStringValue wrappers. If we encounter an unresolved argument, we need to unwrap such a TypedStringValue and then try to treat its content as a class name.
Issue: SPR-11034
Also optimized getTypeForFactoryMethod's implementation for non-generic factory methods, and reduced calls to getResolvedFactoryMethod in order to avoid repeated synchronization.
Issue: SPR-11034
DefaultListableBeanFactory performs a fallback check for autowire candidates now, which GenericTypeAwareAutowireCandidateResolver implements to accept raw type matches if the target class has unresolvable type variables. Full generic matches are still preferred; the BeanFactory will only start looking for fallback matches if the first pass led to an empty result.
Issue: SPR-10993
Issue: SPR-11004
Update TypeConverterDelegate to bypass conversion when the target type
is Object.class. Prior to this commit converting a single element array
to an Object would result in the element being returned, rather than
the array itself.
Issue: SPR-10996
- Now avoiding NullPointerExceptions in GenericTypeResolver's
resolveReturnTypeForGenericMethod() in case the supplied ClassLoader
is null.
- AutowireUtils.resolveReturnTypeForFactoryMethod() now properly
asserts that the supplied ClassLoader is not null.
- Fixed copy-n-paste errors in Javadoc for
AutowireUtils.resolveReturnTypeForFactoryMethod().
Issue: SPR-10411
Includes revisions of MethodParameter and DependencyDescriptor (in particular towards a reference to the containing class). Also refines several ResolvableType method signatures.
Issue: SPR-9965
We're consistently resolving class names now, and the entire algorithm moved from GenericTypeResolver to the internal AutowireUtils helper in the bean factory package.
Issue: SPR-10411
A few noteworthy minor changes: LocaleContext.getLocale() may return null in special cases (not by default), which our own accessing classes are able to handle now. If there is a non-null TimeZone user setting, we're exposing it to all collaborating libraries, in particular to JSTL, Velocity and JasperReports. Our JSR-310 and Joda-Time support falls back to checking the general LocaleContext TimeZone now, adapting it to their time zone types, if no more specific setting has been provided. Our DefaultConversionService has TimeZone<->ZoneId converters registered. And finally, we're using a custom parseTimeZoneString method now that doesn't accept the TimeZone.getTimeZone(String) GMT fallback for an invalid time zone id anymore.
Issue: SPR-1528
Also internally renaming SimpleNonIndexedPropertyDescriptor to SimplePropertyDescriptor and preferring direct field access wherever possible.
Issue: SPR-10862
(cherry picked from commit 5639aa7)
Also, DefaultListableBeanFactory logs a warning when overriding an application definition with a framework-generated definition now, which is expected to be an accident.
Issue: SPR-10607
This turned into a rather huge affair since it led to the introduction of a new AutowireCandidateResolver implementation in the spring-context module. That ACR impl is now being set through AnnotationConfigUtils; GenericApplicationContext and co do not set a default QualifierAnnotationAutowireCandidateResolver anymore (which has always been a smell anyway). At the same time, dependency ordering has moved from AutowiredAnnotationBeanPostProcessor to DefaultListableBeanFactory itself through a "dependencyComparator" strategy, applying to constructor dependencies and lazy resolution proxies as well.
Issue: SPR-10353
Also fixing an old XmlBeanFactory test that relies on "ref local" which is gone in the 4.0 xsd now, redeclaring the affected file to an older xsd version.
Also, StandardReflectionParameterNameDiscoverer calls "Parameter.isNamePresent()" now to return null (and pass on to the next discoverer) if no JDK 8 parameters are available. Note that this requires OpenJDK 8 b100 or higher to compile now.
Issue: SPR-10532
Juergen Hoeller
Stephane Nicoll
Seo, Kyung-Seok
Min Ho Pak
Stephane Nicoll
Rossen Stoyanchev
Alex Yursha
Sam Brannen
Phillip Webb
Eric Dahl