Driven by the need for implementing Bean Validation 1.1's "releaseInstance" method in SpringConstraintValidatorFactory, as a direct counterpart to the use of AutowireCapableBeanFactory's "createBean(Class)" in "getInstance".
Issue: SPR-8199
Prior to this change, CallbacksSecurityTests#testContainerPrivileges was
@Ignored because it caused the build to fail under Gradle. After some
analysis, the root cause was determined to be the fact that (a) a
restrictive SecurityManager is active during the running of this test,
and (b), Gradle intercepts System.out and routes it through its internal
LogBack-based logging system. LogBack requires a call to
Class#getClassLoader when handling logging statements, and the
SecurityManager disallows this call, thus raising the error that fails
the build.
This commit solves the problem by eliminating the System.out.println
call in question and removing the @Ignore annotation from the test. The
console output was diagnostic in nature anyway, and not required for the
successful execution of the test's assertions.
Issue: SPR-10074
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
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)
Prior to this change, spring-beans contained its own META-INF containing
spring.handlers and spring.schemas files in src/main/resources; it also
had files of the same name within src/test/resources/META-INF, causing
'duplicate resource' warnings and confusion in general.
This commit moves the com.foo test package, it's associated namespace
parsing tests and test versions of META-INF files to the root project
and it's src/test integration testing folder.
Issue: SPR-9431
* cleanup-test-duplicates:
Update Apache license headers for affected sources
Remove duplicate test classes
Replace test beans with test objects
Conflicts:
spring-beans/src/test/java/org/springframework/beans/factory/ConcurrentBeanFactoryTests.java
spring-beans/src/test/java/org/springframework/beans/support/PagedListHolderTests.java
Prior to this commit many test utility classes and sample beans were
duplicated across projects. This was previously necessary due to the
fact that dependent test sources were not shared during a gradle
build. Since the introduction of the 'test-source-set-dependencies'
gradle plugin this is no longer the case.
This commit attempts to remove as much duplicate code as possible,
co-locating test utilities and beans in the most suitable project.
For example, test beans are now located in the 'spring-beans'
project.
Some of the duplicated code had started to drift apart when
modifications made in one project where not ported to others. All
changes have now been consolidated and when necessary existing tests
have been refactored to account for the differences.
Conflicts:
spring-beans/src/test/java/org/springframework/beans/factory/ConcurrentBeanFactoryTests.java
spring-beans/src/test/java/org/springframework/beans/factory/support/BeanFactoryGenericsTests.java
spring-beans/src/test/java/org/springframework/beans/support/PagedListHolderTests.java
- Add TestGroup#LONG_RUNNING to distinguish from #PERFORMANCE, the
former being tests that simply take a long time vs the latter being
tests that are actually dependent on certain actions happening within
a given time window and are thefore CPU-dependent.
Issue: SPR-9984
Move code from spring-build-junit into spring-core/src/test along with
several other test utility classes. This commit removes the temporary
spring-build-junit project introduced in commit
b083bbdec7.
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
Make use of the new JUnit functionality introduced in the previous
commit to 'Assume' that perfomance- and timing-sensitive tests should
run only when TestGroup.PERFORMANCE is selected, i.e. when
-PtestGroups="performance" has been provided at the Gradle command line.
The net effect is that these tests are now ignored by default, which
will result in far fewer false-negative CI build failures due to
resource contention and other external factors that cause slowdowns.
We will set up a dedicated performance CI build to run these tests on
an isolated machine, etc.
Issue: SPR-9984
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.
Remove the 'final' modifier from SingletonBeanFactoryLocatorTests
to work around the "cannot extend final class" error issued when
running all tests. The error was due to confusion with IDEA between
the two variants of SingletonBeanFactoryLocatorTests across
spring-context and spring-beans.
Rename one of the GroovyMessenger classes to GroovyMessenger2.
Previously there were multiple Groovy classes named
'GroovyMessenger', causing a compilation error in certain IDE
arrangements.
Update import-into-idea.md documentation
Add various IDEA artifacts to .gitignore
- ignore derby.log wherever it is written
- ignore IDEA's test-output directory
- ignore IDEA's Atlassian connector config file
Documented why static nested test cases in the spring-test module are
ignored, explaining that such "TestCase classes are run manually by the
enclosing test class". Prior to the migration to Gradle (i.e., with
Spring Build), these tests would not have been picked up by the test
suite since they end with a "TestCase" suffix instead of "Test" or
"Tests".
Re-enabled HibernateMultiEntityManagerFactoryIntegrationTests.
For the remaining tests that were disabled as a result of the migration
to Gradle, comments have been added to the @Ignore declarations.
Issue: SPR-8116, SPR-9398
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
- Increase max heap size in gradle wrapper.
- Use MockProperties implementation to protect against security
exceptions.
- Replace windows CRLF with LF in various tests.
- Increase Thread.sleep times to account for lack of precision on
Windows.
Issue: SPR-9717
This commit refactors the BeanInfoFactory so that:
- supports() and getBeanInfo() are folded into one, so that getBeanInfo()
returns null if a given class is not supported.
- CachedIntrospectionResults now uses SpringFactoriesLoader
Prior to this change, CachedIntrospectionResults delegated to
ExtendedBeanInfo by default in order to inspect JavaBean
PropertyDescriptor information for bean classes.
Originally introduced with SPR-8079, ExtendedBeanInfo was designed to
go beyond the capabilities of the default JavaBeans Introspector in
order to support non-void returning setter methods, principally to
support use of builder-style APIs within Spring XML. This is a complex
affair, and the non-trivial logic in ExtendedBeanInfo has led to various
bugs including regressions for bean classes that do not declare
non-void returning setters.
This commit takes advantage of the new BeanInfoFactory mechanism
introduced in SPR-9677 to take ExtendedBeanInfo out of the default code
path for CachedIntrospectionResults. Now, the new
ExtendedBeanInfoFactory class will be detected and instantiated (per its
entry in the META-INF/spring.beanInfoFactories properties file shipped
with the spring-beans jar). ExtendedBeanInfoFactory#supports is invoked
for all bean classes in order to determine whether they are candidates
for ExtendedBeanInfo introspection, i.e. whether they declare non-void
returning setter methods.
If a class does not declare any such non-standard setter methods (the
99% case), then CachedIntrospectionResults will fall back to the
default JavaBeans Introspector. While efforts have been made to fix any
bugs with ExtendedBeanInfo, this change means that EBI will not pose
any future risk for bean classes that do not declare non-standard
setter methods, and also means greater efficiency in general.
Issue: SPR-9723, SPR-9677, SPR-8079
- Ensure that ExtendedBeanInfoTests succeeds when building under JDK 7
- Improve handling of read and write method registration where
generic interfaces are involved, per SPR-9453
- Add repro test for SPR-9702, in which EBI fails to register
an indexed read method under certain circumstances
Issue: SPR-9702, SPR-9414, SPR-9453
