Update AbstractAutowireCapableBeanFactory.getTypeForFactoryBean to
check AbstractBeanDefinition.hasBeanClass() before calling
getBeanClass(). The protects against a 'Bean class name [<name>] has
not been resolved into an actual Class' IllegalStateException.
Issue: SPR-10304
This change means that we effectively revert SPR-8954's code change in favor of the isFactoryBean implementation simply relying on predictBeanType to sort it out, filtering a post-processed predictedType for FactoryBean applicability.
Issue: SPR-9177
Issue: SPR-9143
Update DefaultListableBeanFactory.getBean(Class<?> beanClass) to
consider the 'primary' attribute of bean definitions. This makes
getBean() behave in the same way as autowiring.
Issue: SPR-7854
Also introduces consistent use of getBean(Class) for similar use cases across the framework, accepting a locally unique target bean even if further matching beans would be available in parent contexts (in contrast to BeanFactoryUtils.beanOfType's behavior).
Issue: SPR-10160
This change resolves a specific issue with processing
java.math.BigDecimal via ExtendedBeanInfo. BigDecimal has a particular
constellation of #setScale methods that, prior to this change, had the
potential to cause ExtendedBeanInfo to throw an IntrospectionException
depending on the order in which the methods were processed.
Because JDK 7 no longer returns deterministic results from
Class#getDeclaredMethods, it became a genuine possibility - indeed a
statistical certainty that the 'wrong' setScale method handling order
happens sooner or later. Typically one could observe this failure once
out of every four test runs.
This commit introduces deterministic method ordering of all discovered
non-void returning write methods in such a way that solves the problem
for BigDecimal as well as for any other class having a similar method
arrangement.
Also:
- Remove unnecessary cast
- Pass no method information to PropertyDescriptor superclasses when
invoking super(...). This ensures that any 'type mismatch'
IntrospectionExceptions are handled locally in ExtendedBeanInfo and
its Simple* PropertyDescriptor variants where we have full control.
Issue: SPR-10111, SPR-9702
Backport-Commit: aa3e0be (forward-ported via cherry-pick from 3.1.x)
Fix deprecation compiler warnings by refactoring code or applying
@SuppressWarnings("deprecation") annotations. JUnit tests of
internally deprecated classes are now themselves marked as
@Deprecated.
Numerous EasyMock deprecation warnings will remain until the
migration to mockito can be completed.
The intention of ExtendedBeanInfo, introduced with SPR-8079 in
v3.1.0.M2, was to support dependency injection against non-void
returning write methods. However, it also inadvertently introduced
support for injection against static setter methods.
When use of ExtendedBeanInfo was made optional with SPR-9723 in
v3.2.0.M2, ExtendedBeanInfo continued to support static write methods,
but its new BeanInfoFactory-based approach to testing whether or not
a given bean class contains candidate write methods was written in a
fashion exclusive of static methods, and this thereby introduced a
regression - a regression in an otherwise undocumented and unintended
feature, but a regression nevertheless.
The reporting of SPR-10115 proves that at least one user has come to
depend on this behavior allowing injection against static write
methods, and so this commit fixes the regression by ensuring that the
candidacy test includes standard and non-void setter methods having a
static modifier.
Issue: SPR-10115, SPR-9723, SPR-8079
Fix serialization warnings by applying @SuppressWarnings("serial")
when appropriate.
In certain cases and for unknown reasons, a correctly-placed
@SuppressWarnings("serial") annotation will fix the warning at the
javac level (i.e. the Gradle command-line), but will produce an
"unnecessary @SuppressWarnings" warning within Eclipse. In these
cases, a private static final serialVersionUID field has been added
with the default value of 1L.
In particular, avoiding synchronized Sets and Maps wherever possible (preferring a ConcurrentHashMap even instead of a synchronized Set) and specifying appropriate ConcurrentHashMap initial capacities (even if we end up choosing 16).
- Support external Javadoc links using Gradle's javadoc.options.links
- Fix all other Javadoc warnings, such as typos, references to
non-existent (or no longer existent) types and members, etc,
including changes related to the Quartz 2.0 upgrade (SPR-8275) and
adding the HTTP PATCH method (SPR-7985).
- Suppress all output for project-level `javadoc` tasks in order to
hide false-negative warnings about cross-module @see and @link
references (e.g. spring-core having a @see reference to spring-web).
Use the `--info` (-i) flag to gradle at any time to see project-level
javadoc warnings without running the entire `api` task. e.g.
`gradle :spring-core:javadoc -i`
- Favor root project level `api` task for detection of legitimate
Javadoc warnings. There are now zero Javadoc warnings across the
entirety of spring-framework. Goal: keep it that way.
- Remove all @link and @see references to types and members that exist
only in Servlet <= 2.5 and Hibernate <= 4.0, favoring 3.0+ and 4.0+
respectively. This is necessary because only one version of each of
these dependencies can be present on the global `api` javadoc task's
classpath. To that end, the `api` task classpath has now been
customized to ensure that the Servlet 3 API and Hibernate Core 4 jars
have precedence.
- SPR-8896 replaced our dependency on aspectjrt with a dependency on
aspectjweaver, which is fine from a POM point of view, but causes
a spurious warning to be emitted from the ant iajc task that it
"cannot find aspectjrt on the classpath" - even though aspectjweaver
is perfectly sufficient. In the name of keeping the console quiet, a
new `rt` configuration has been added, and aspectjrt added as a
dependency to it. In turn, configurations.rt.asPath is appended to
the iajc classpath during both compileJava and compileTestJava for
spring-aspects.
Issue: SPR-10078, SPR-8275, SPR-7985, SPR-8896
Previously, CachedIntrospectionResults had three modes of caching, with the intermediate mode relying on WeakReferences in the JDK PropertyDescriptor implementation. Since the JDK is actually using SoftReferences there these days, losing information in case of a GC run with tough memory constraints, we want to allow for hard references in PropertyDescriptor objects and therefore use a full WeakReference for the CachedIntrospectionResults object itself.
Issue: SPR-10028
This change revisits the implementation of ExtendedBeanInfo, simplifying
the overall approach while also ensuring that ExtendedBeanInfo is fully
isolated from the BeanInfo instance it wraps. This includes any existing
PropertyDescriptors in the wrapped BeanInfo - along with being copied
locally into ExtendedBeanInfo, each property descriptor is now also
wrapped with our own new "simple" PropertyDescriptor variants that
bypass the soft/weak reference management that goes on in both
java.beans.PropertyDescriptor and java.beans.IndexedPropertyDescriptor,
maintaining hard references to methods and bean classes instead. This
ensures that changes we make to property descriptors, e.g. adding write
methods, do not cause subtle conflicts during garbage collection (as was
reported and reproduced in SPR-9702).
Eliminating soft/weak reference management means that we must take extra
care to ensure that we do not cause ClassLoader leaks by maintaining
hard references to methods, and therefore transitively to the
ClassLoader in which the bean class was loaded. The forthcoming
SPR-10028 addresses this aspect.
See the updated ExtendedBeanInfo Javadoc for further details.
Issue: SPR-8079, SPR-8175, SPR-8347, SPR-8432, SPR-8491, SPR-8522,
SPR-8806, SPR-8931, SPR-8937, SPR-8949, SPR-9007, SPR-9059,
SPR-9414, SPR-9453, SPR-9542, SPR-9584, SPR-9677, SPR-9702,
SPR-9723, SPR-9943, SPR-9978, SPR-10028, SPR-10029
In particular, the specified object name may use a placeholder for its domain part now, allowing for several instances of the MBean to be registered against the same MBeanServer from different applications.
Issue: SPR-8244
Allow the body of 'arg-type' XML elements to be used as an alternative to
'match' attribute when defining a 'replace-method' in XML configuration.
This change has been introduced primarily to support the samples printed
in the Apress 'Pro Spring' book.
Issue: SPR-9812
