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
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)
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
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
