- 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.
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
- Suppress rawtypes warnings for src/main
- Enable rawtypes warnings for src/test
This commit attempts to to resolve all rawtypes problems across tests as
aggressively as possible, i.e. without regard for binary compatibility,
whereas main sources must be treated much more cautiously with an eye
toward compatibility.
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
Refactor MBean Server reset code from MBeanServerFactoryBeanTests
and reuse in AdvisedJRubyScriptFactoryTests and
AbstractMBeanServerTests.
Issue: SPR-9288
Prior to this commit the testWithLocateExistingAndExistingServer method
would fail if any preceding test called the ManagementFactory
getPlatformMBeanServer() method. In such situations the platform
server is located instead of the expected freshly created server.
These failures are more likely to happen when compiling with JDK 7
due to the fact that the reflection API no longer returns methods
in a consistent order.
Unfortunately there is no easy way to reset the platform MBean server
so the new code must resort to using reflection to access the private
static ManagementFactory.platformMBeanServer field.
Issue: SPR-9288
In the course of this enhancement, the "cache.ehcache" and "cache.jcache" packages moved from spring-context to the spring-context-support module, expecting further transaction-related functionality. Also aligns with the presence of Spring's Quartz support in the spring-context-support module, since Quartz and EHCache are sort of sister projects at Terracotta now.
Issue: SPR-9966
Implementations of Spring's ImportBeanDefinitionRegistrar interface may
now implement any of the following *Aware interfaces and have their
respective methods called prior to #registerBeanDefinitions:
- BeanFactoryAware
- BeanClassLoaderAware
- ResourceLoaderAware
Issue: SPR-9568
Refactor DateTimeFormatterFactory into two distinct classes; a general
purpose factory and a specialized FactoryBean. These changes are
modeled after the existing VelocityEngineFactory and
VelocityEngineFactoryBean classes.
Issue: SPR-9959
The DateTimeFormatterFactory introduced in SPR-7121 supports a timeZone
property; however, this property is currently not properly supported.
This commit addresses this issue by ensuring that the timeZone properly
is honored.
Issue: SPR-9953
Added dateFormatter, timeFormatter and dateTimeFormatter properties
to JodaTimeFormatterRegistrar allowing for custom global formatting.
DateTimeFormatterFactory can be used when configuring with XML.
Issue: SPR-7121
Dependency on Joda Time when using the @DateTimeFormat annotation is
now optional. If Joda Time is not present the JDK SimpleDateFormat
will be used to parse and print date patterns. If Joda time is
present it will always be used in preference to SimpleDateFormat.
Issue: SPR-6508
Prior to this commit, calls to ConfigurableEnvironment#addActiveProfile
would cause any active profile values provided via the
"spring.profiles.active" property to be ignored.
Now these two mechanisms can be used in conjunction and work as
expected.
Issue: SPR-9944
Refactor ConfigurationClassParser to recursively find values from
all @Import annotations, combining them into a single unique set.
This change prevents ImportBeanDefinitionRegistrars from being
invoked twice.
Issue: SPR-9925
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
This commit refactors changes introduced in 21760a8 as follows:
- Introduce top-level MessageCodeFormatter interface and
DefaultMessageCodesResolver#setMessageCodeFormatter property to allow
for user-defined message code formatting strategies
- Rename DefaultMessageCodesResolver.Style enum => DMCR.Format
- Refactor DefaultMessageCodesResolver.Format to implement the new
MessageCodeFormatter interface
The result is that users have convenient access to common formatting
strategies via the Format enum, while retaining the flexibility to
provide their own custom MessageCodeFormatter implementation if desired.
See DefaultMessageCodesResolverTests#shouldSupport*Format tests for
usage examples.
Issue: SPR-9707
Introduce new 'style' property to DefaultMessageCodesResolver allowing
for alternative message styles. Current styles are PREFIX_ERROR_CODE
and POSTFIX_ERROR_CODE. The default style retains existing behavior.
Issue: SPR-9707
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
Prior to this commit, @EnableMBeanExport was declared in the
jmx.export.annotation package. This makes logical sense, but
nevertheless creates a package cycle, because @EnableMBeanExport depends
on MBeanExportConfiguration which in turn depends on context.annotation
types like @Configuration, @Bean, and @Role.
context.annotation.config.MBeanExportBeanDefinitionParser, on the other
hand already has dependencies on types in jmx.support. Together, this
means that a package cycle was introduced.
The solution to this is simple: move @EnableMBeanExport and friends from
jmx.export.annotation => context.annotation. This has been the strategy
for other @Enable annotations and for the same reasons. It also makes a
kind of logical sense: just like you find <context:mbean-export> and
<context:load-time-weaver> under the context: XML namespace, so too do
you find their @Enable* counterparts under the context.annotation
namespace.
Issue: SPR-8943
Add support for @EnableMBeanExport annotation allowing @Configuration
classes to easily export all MBeans and @ManagedResources from the
Spring application context. The annotation is functionally equivalent
to the XML <context:mbean-export/> element.
Issue: SPR-8943
Reverted change for @Bean methods that declare FactoryBean as their return type: The effects of trying to create the FactoryBean to find out about its implementation type are too far-reaching. It's better to recommend declaring a specific return type in the method signature if you want the container to specifically react to your implementation type.
Issue: SPR-9857
Includes a change for factory methods that declare their return type as FactoryBean: When asked for a specific type match (e.g. LoadTimeWeaverAware), we do check early singleton instances as well (reusing the instances that we create for getObjectType checks). This is necessary in order to make @Bean method introspection as capable as XML bean definition introspection, even in case of the @Bean method using a generic FactoryBean declaration for its return type (instead of the FactoryBean impl class).
Issue: SPR-9857
Includes a change for factory methods that declare their return type as FactoryBean: When asked for a specific type match (e.g. LoadTimeWeaverAware), we do check early singleton instances as well (reusing the instances that we create for getObjectType checks). This is necessary in order to make @Bean method introspection as capable as XML bean definition introspection, even in case of the @Bean method using a generic FactoryBean declaration for its return type (instead of the FactoryBean impl class).
Issue: SPR-9857
Chris Beams
Phillip Webb
Juergen Hoeller
Oliver Gierke
Sam Brannen
Gareth Davis