Prior to this commit, calls to getAllow would fail is setAllow was set
to an EmptyCollection right before.
java.lang.IllegalArgumentException: No enum constant
org.springframework.http.HttpMethod
This commit fixes this by testing the header value for an empty value
before trying to use it to get a value from the Enum.
Issue: SPR-11917
(cherry picked from commit 9054f4f)
This commit also includes lazy resolution support for StandardServletMultipartResolver, along the lines of existing lazy mode in CommonsMultipartResolver.
Issue: SPR-11074
Issue: SPR-11730
(cherry picked from commit 82336c3)
Prior to this commit, if multiple test methods were executed in a
subclass of AbstractTestNGSpringContextTests annotated with
@WebAppConfiguration, then injected Servlet API mocks would only
reference the mocks created for the first test method. Subsequent test
methods could therefore never reference the current mocks, and there
was a discrepancy between the state of the injected mocks and the mock
set in the RequestContextHolder.
This commit addresses this issue by ensuring that dependencies
(including updated mocks) are injected into the test instance before
the next test method if the ServletTestExecutionListener resets the
request attributes in RequestContextHolder.
Issue: SPR-11626
(cherry picked from commit c38600762d)
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
(cherry picked from commit 5308b3e)
Also uses addAll instead of iteration over untyped collection now, supporting optimized addAll in target collection type, and avoids repeated getElementTypeDescriptor calls.
Issue: SPR-11479
(cherry picked from commit bea94d5)
When a node of an SPeL expression was a call to a bean referenced
in a method argument, the expression was resolved twice.
The resolved arguments are now specified to MethodValueRef instead
of resolving the arguments again in the constructor
Issue: SPR-11445
(cherry picked from commit 519799e)
This change removes the use of a CountDownLatch to wait for the
asynchronously computed controller method return value. Instead we
check in a loop every 200 milliseconds if the result has been set.
If the result is not set within the specified amount of time to wait
an IllegalStateException is raised.
Additional changes:
- Use AtomicReference to hold the async result
- Remove @Ignore annotations on AsyncTests methods
- Remove checks for the presence of Servlet 3
Issue: SPR-11516
Update ConcurrentReferenceHashMap to protect against references that
have been garbage collected but for some reason do not appear as a
`pollForPurge` result.
Also added purgeUnreferencedEntries() method to allow for programmatic
cleanup.
Issue: SPR-11440
(cherry picked from commit 2b4c81e6)
Replaced static import of org.junit.Assert.* with implicit imports in
order to avoid ambiguity between JUnit's static Assert methods and those
in org.custommonkey.xmlunit.XMLAssert.
This commit introduces a test in XmlBeanFactoryTests that verifies that
CGLIB generated subclasses for method injected beans are reused across
bean factories for identical bean definitions. In other words, by
verifying that the same CGLIB generated class is reused for identical
bean definitions, we can be certain that Spring is no longer generating
identical, duplicate classes that consume memory in the VM.
Issue: SPR-10785, SPR-11420
(cherry picked from commit f2a4537)
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
(cherry picked from commit 9534245)
MarshallingView also explicitly skips BindingResult when searching for a model object now, implementing common custom subclass behavior out-of-the-box.
Issue: SPR-11411
Issue: SPR-11417
Before this change the getPathWithinServletMapping method of
UrlPathHelper could not work properly when a default servlet mapping
(i.e. "/") was used in combination with urlDecode=false. The fact that
the getServletPath() method of HttpServletRequest always returns a
decoded path was getting in the way.
Although there is no way to check Servlet mappings through the Servlet
API, this change aims to detect the given scenario and returns the full
path following the context path thus avoiding URL decoding.
Note that the same can be achieved by setting urlDecode=false and
alwaysUseFullPath=true. However this change ensures that urlDecode
works properly without having to know that.
Issue: SPR-11101
(cherry picked from commit 12598f8)
This requires consistent exposure of an actualValue in BindStatus, even if no BindingResult available.
Issue: SPR-10837
(cherry picked from commit 4f60b98)
Prior to this commit, RestTemplate's constructors were all initializing
default HTTPMessageConverters. Its API provides a way to replace
those converters with custom ones, but default converters are already
defined and initialized at that point, which can be an issue in some
cases (performance, classpath...).
This commits adds a new constructor for RestTemplate with a list
of message converters as argument. With this new constructor,
default message converters are never initialized.
Issue: SPR-11351
(cherry picked from commit 425e5a0)
Commons Pool 1.6 introduced generics in its APIs, leading to either a 1.6 dependency at runtime or a load of raw type warnings in our CommonsPoolTargetSource.
JOpt 4.6 redeclared its nonOptionArguments() method from List<String> to List<?>, requiring us to select String arguments only as we do for regular option values already.
Issue: SPR-11359
(cherry picked from commit 67e76e9)
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
(cherry picked from commit 8543b91)
Prior to this commit, a NoClassDefFoundError caught in
TestContextManager's retrieveTestExecutionListeners() method would be
handled differently for implicit default listeners (i.e., listeners not
declared via @TestExecutionListeners) and listeners explicitly declared
via @TestExecutionListeners. Specifically, a NoClassDefFoundError would
cause a test to fail for an explicitly declared TestExecutionListener
but not for an implicitly declared one.
This commit addresses this issue by:
- Always swallowing a NoClassDefFoundError for both implicitly and
explicitly declared TestExecutionListeners.
- Changing the log level from DEBUG to INFO to make such situations
more visible to the average end user.
Issue: SPR-11347
Backport-Commit: fb12e234fc
Fixed through downcasting to AspectJ's ReflectionType and ReflectionBasedReferenceTypeDelegate, obtaining the myClass field there. We only fall back to regular class loading if we encounter any other kind of type.
Issue: SPR-11344
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
(cherry picked from commit a599b57)
The ServletTestExecutionListener is now prepended to the set of default
listeners in AbstractJUnit4SpringContextTests and
AbstractTestNGSpringContextTests.
Issue: SPR-11340
Backport-Commit: 3370f8b1b1
Prior to this commit TestNG tests would only be executed by the Gradle
build if they were located in the “testng” package. Tests in subpackages
would therefore be omitted from the build.
This commit ensures that all TestNG classes in the “testng” package and
any of its subpackages are executed in the Gradle build.
Furthermore, this commit ensures that the JUnit-based
FailingBeforeAndAfterMethodsTests test class is executed along with the
other JUnit tests even though it resides under the “testng” package.
Issue: SPR-11338
Backport-Commit: 098d7c7465
While we've had basic Quartz 2.2 support before, a few details were missing:
* LocalDataSourceJobStore's ConnectionProvider adapters need to provide an empty implementation of Quartz 2.2's new initialize method.
* SchedulerFactoryBean's "schedulerContextMap" needs to be explicitly declared with String keys, otherwise it can't be compiled against Quartz 2.2 (forward compatibility once we're dropping Quartz 1.x support). This doesn't hurt against older Quartz versions either, since the keys need to be Strings anyway.
Issue: SPR-11284
(cherry picked from commit 38a8ace)
Also simplified cache key 'hashCode' implementation, relying on 'equals' to differentiate between same method on different target classes.
Issue: SPR-11267
(cherry picked from commit 82ea9ec)
This turned out to be a bug in the ASM-based AnnotationMetadata implementation where has/getAnnotatedMethods didn't consider meta-annotations., in contrast to its StandardAnnotationMetadata sibling.
Issue: SPR-10488
(cherry picked from commit 105e176)
This commit makes several methods of TestContext non-final in order to
allow TestContext to be mocked — for example with Mockito.
Note, however, that TestContext has been converted to an interface in
Spring Framework 4.0.
Issue: SPR-11144
This commit fixes a bug introduced in the last commit.
ServletTestExecutionListener (STEL) now tracks whether it has already
populated the RequestContextHolder.
Issue: SPR-11144
Backport-Commit: 800018a817
The previous commit for issue SPR-11144 revealed a bug in
ServletTestExecutionListener (STEL). Specifically, STEL acted on the
fact that the ApplicationContext for a given TestContext was an
instance of WebApplicationContext. This behavior could potentially
break test code from previous releases of the Spring Framework that
relied on a custom setup of the RequestAttributes in the
RequestContextHolder with a custom WebApplicationContext ContextLoader.
This commit addresses this issue by ensuring that STEL only comes into
play if the test class is annotated with @WebAppConfiguration (for
prepareTestInstance() and beforeTestMethod()) or if the TestContext
attribute named RESET_REQUEST_CONTEXT_HOLDER_ATTRIBUTE is set to
Boolean.TRUE (for afterTestMethod()).
Issue: SPR-11144
Backport-Commit: 099b10d23b
Specifically, read and write methods are allowed to express property types with superclass/subclass relationships in both directions now.
Issue: SPR-11139
(cherry picked from commit cb624e2)
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
(cherry picked from commit 242ecdc)
Prior to this commit, the ServletTestExecutionListener did not
overwrite RequestAttributes in the RequestContextHolder if the
ApplicationContext associated with the given TestContext was not a
WebApplicationContext; however, the ServletTestExecutionListener would
clear the RequestAttributes after every test method execution,
regardless of whether the context was a WebApplicationContext or not.
This behavior breaks backwards compatibility with integration tests
that managed the RequestAttributes in RequestContextHolder themselves.
This commit addresses this issue by introducing a TestContext attribute
named RESET_REQUEST_CONTEXT_HOLDER_ATTRIBUTE in
ServletTestExecutionListener. This attribute is used internally within
ServletTestExecutionListener to ensure that the RequestContextHolder is
only cleared (i.e., reset) if the ServletTestExecutionListener actually
populated the RequestContextHolder.
Issue: SPR-11144
Backport-Commit: a3b022aa48
Fix regression introduced in b25e91a5 where ReflectivePropertyAccessor
does not consider the return type for "is" getters.
Issue: SPR-11142
(cherry picked from commit 85b0bfff)
Fix CacheAspectSupport to consider a cache hit from any of the multiple
@Cachables that may have been specified using the @Caching annotation.
Prior to this commit the following scenario would never produce a hit:
@Caching(cacheable = {
@Cacheable(value = "c1", unless = "#result.size() < 4"),
@Cacheable(value = "c2", unless = "#result.size() > 3")
})
Issue: SPR-11124
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
(cherry picked from commit b093b84)
This change adds async web request timeout handling to OSIV filters
and interceptors to ensure the session or entity manager is released.
Issue: SPR-10874
This change avoid use of AntPathMatcher to extract URI template
variables when the lookup path is used as the best matching pattern.
Issue: SPR-10803
(cherry picked from commit a7af950)
Relax the method search algorithm used by `ReflectivePropertyAccessor`
to include methods of the form `getXY()` for properties of the form
`xy`.
Although the JavaBean specification indicates that a property `xy`
should use the accessors `getxY()` and `setxY()`, in practice many
developers choose to have an uppercase first character. The
`ReflectivePropertyAccessor` will now consider these style methods if
the traditional conventions fail to find a match.
Issue: SPR-10716
(cherry picked from commit b25e91a5)
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
(cherry picked from commit c9aace4d)
Update the `CacheKey` class used by `ReflectivePropertyAccessor` to
include if the target object is class. The prevents an incorrect cache
hit from being returned when a property with the same name is read on
both an object and its class. For example:
#{class.name}
#{name}
Issue: SPR-10486
(cherry picked from commit 6d882b14)
Update `AbstractApplicationEventMulticaster` to support `EventObjects`
with a null source (which can happen if they have been serialized).
Issue: SPR-10945
(cherry picked from commit b0ff834e)
Ensure that property source locations are processed in the same order
regardless if the 'name' attribute is set or not.
Prior to this commit multiple locations from a `@PropertySource` with
a name were added to a `CompositePropertySource` in such a way that
the first location would take precedence. This has now been reversed
for consistence with unnamed `@PropertySource`s
Issue: SPR-10820
(cherry picked from commit e3d3d8cd)
Also using ClassUtils.forName in AutowireUtils now in order to accept all common class name formats.
Issue: SPR-11034
(cherry picked from commit 8c1767e)
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
Optimized getTypeForFactoryMethod's implementation for non-generic factory methods, and reduced calls to getResolvedFactoryMethod in order to avoid repeated synchronization. Derived from work around SPR-11034.
Prior to this commit, the uniqueness check for @ContextConfiguration
attributes within a @ContextHierarchy was performed at a single test
class level instead of against the merged configuration for all test
class levels in the test class hierarchy.
This commit addresses this issue by moving the uniqueness check
algorithm from resolveContextHierarchyAttributes() to
buildContextHierarchyMap() within ContextLoaderUtils.
Issue: SPR-11011
Backport-Commit: 7658d856ca
Update getValue(EvaluationContext context, Object rootObject,
Class<T> desiredResultType) to propagate the EvaluationContext to
ExpressionUtils.
Issue: SPR-10953
(cherry picked from 686cd79)
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
(cherry picked from commit 8b1927f)
This fine-tuned change restores the original Spring 3.0 behavior for Oracle AQ, and also allows for other ConnectionFactory types to comply with the "getDataSource()" pattern.
Issue: SPR-10829
(cherry picked from commit 11d20e3)
S0 doesn't seem to be universally used for SQL grammar problems: see MS SQL Server's RAISERROR. This was reported years back; not sure why the fix didn't actually appear in the codebase back then.
Issue: SPR-10902
(cherry picked from commit d9b6203)
Update CallMetaDataContext to use the metaDataProvider
createDefaultOutParameter method when creating a SqlOutParameter as
a result of a SQL function call.
This change allows Spring to support Oracle cursor types when returned
from functions.
Issue: SPR-10606
(cherry picked from c16b21)
Replace "Problem locating method {0} cannot on type {1}" with
"Problem locating method {0} on type {1}".
Issue: SPR-10928
(cherry picked from 824ac5)
Conflicts:
spring-expression/src/main/java/org/springframework/expression/spel/SpelMessage.java
Also internally renaming SimpleNonIndexedPropertyDescriptor to SimplePropertyDescriptor and preferring direct field access wherever possible.
Issue: SPR-10862
This commit includes a full backport of the changes in SPR-10657, instead of just the initial commit which the original backport request referred to.
Issue: SPR-10884
Issue: SPR-10657
In the given example the expression using the Elvis operator will
return "Nikola Tesla" and not "Mike Tesla".
Issue: SPR-10850
(cherry picked from commit 84242f1)
MockFilterChain should not be re-used across requests. This is not an
issue unless tests are executed concurrently. This change ensures the
MockFilterChain is re-created for each request in MockMvc.
Issue: SPR-10838
ResourceHttpMessageConverter tries to use the filename to determine the
media type, but for Resource implementations such as ByteArrayResource
it is null, which causes NullPointerException. The fix checks whether
getFilename returns null before attempting to determine the media type
by it.
Issue: SPR-10848
Added XStream CatchAllConverter that supports all classes, but throws
exceptions for (un)marshalling.
Main purpose of this class is to register this converter as a catchall
last converter with a normal or higher priority in addition to
converters that explicitly support the domain classes that should be
supported. As a result, default XStream converters with lower
priorities and possible security vulnerabilities do not get invoked.
Issue: SPR-10821
Update ClassPathJaxb2TypeScanner to scan for @XmlRegistry classes.
Prior to this commit explicitly configured @XmlRegistry annotated classes
were not registered with the JAXBContext when using the 'packagesToScan'
property of the Jaxb2Unmarshaller.
Issue: SPR-10714
(cherry picked from 4f871d4)
Update the cached MethodExecutor in MethodReference to include the
method argument types. Prevents the incorrect use of the cache when the
SpEL expression refers to a class that has overloaded methods.
Issue: SPR-10657
(cherry picked from commit f9b12b8)
Update META-INF/MANIFEST.MF for spring-instrument to include
necessary attributes for running under Java 7:
Can-Redefine-Classes : true
Can-Retransform-Classes: true
Can-Set-Native-Method-Prefix : false
(see http://docs.oracle.com/javase/7/docs/api/java/lang/instrument/
package-summary.html)
Prior to this commit `InstrumentationSavingAgent.getInstrumentation().
addTransformer(t, true);` would fail under Java 7.
Issue: SPR-10731
(Cherry picked from 50333ca)
Update @Transactional reference documentation to fix the case of the
rollbackForClassName and noRollbackForClassName attributes.
Issue: SPR-10754
(cherry picked from 1204d2a)
Fix PersistenceUnitReader to correctly read <exclude-unlisted-classes>
in both JPA 1.0 and 2.0 persistence.xml files.
Prior to this commit PersistenceUnitReader would set the value of
excludeUnlistedClasses to true when a <exclude-unlisted-classes> element
was present, regardless of its value.
The following rules are now used when parsing:
- If the <exclude-unlisted-classes> element is missing the appropriate
default value is set (based on the JPA version).
- If an empty <exclude-unlisted-classes/> element is found the
excludeUnlistedClasses property is set to true.
- Otherwise the value of the <exclude-unlisted-classes> element is used
to set the excludeUnlistedClasses property.
Issue: SPR-10767
(cherry picked from 7ad540d)
Conflicts:
spring-orm/src/main/java/org/springframework/orm/jpa/persistenceunit/PersistenceUnitReader.java
Port the latest unreleased UndeclaredThrowableStrategy implementation
from cglib to fix a memory-leak present in v3.
Issue: SPR-10709
(cherry picked from 587877c)
Make ConfigurationClassPostProcessor Ordered.HIGHEST_PRECEDENCE in
case several BeanDefinitionRegistryPostProcessors are registered.
Issue: SPR-10645
(cherry picked from 350cb9b)
Added 'processExternalEntities' property to the JAXB2Marshaller, which
indicates whether external XML entities are processed when
unmarshalling.
Default is false, meaning that external entities are not resolved.
Processing of external entities will only be enabled/disabled when the
Source} passed to #unmarshal(Source) is a SAXSource or StreamSource. It
has no effect for DOMSource or StAXSource instances.
The following commit in 3.2.3 had a side effect on CNVR:
https://github.com/SpringSource/spring-framework/commit/aaded7e30b06cc70a354856a2288acd04045b673
It appears that CNVR doesn't treat a request for "*/*" differently
from a request that does not request content types. Both should be
interpreted as "any content type is acceptable". This fix ensures
that CNVR treats these two cases the same way.
Issue: SPR-10683
SPR-10402 in Spring Framework 3.2.3 treated empty request parameter
values as missing values, if the empty value was turned into a null
by a PropertyEditor or Converter. This caused the regression.
Issue: SPR-10578, SPR-10402, SPR-10584
This change involves a modification of the "writeContent" template method to include the "jsonPrefix" String instead of the "prefixJson" boolean flag. Since said template method has only been introduced in 3.2.2, this change should hopefully not be a problem.
Issue: SPR-10567
(cherry picked from commit 28164b4)
Previously ConfigurationClassParser could override a nested
@Configuration without consideration of @Bean's defined in parent
classes.
This commit ensures that if the original ConfigurationClass contains
additional bean definitions it is processed again.
Issue: SPR-10546
Commit 5b1165 was an attempt to leave semicolon content in the URL path
while ignoring it for request mapping purposes. However, it becomes
quite difficult to manage and semicolon content should not always be
ignored (sometimes a semicolon is used as a separator of multiple items
in a path segment, rather than for matrix variables).
This change effectively reverts back to the original approach in 3.2
where a flag on AbstractHandlerMapping can be used to have semicolon
content removed or kept. If kept, path segments with matrix variables
must be represented with a path segment.
The main difference is that by default it is removed everywhere
including the MVC namespace and Java config.
Issue: SPR-10427, SPR-10234
Previously DeferredResult locked around the setting of the result
including handling up to the part of submitting a dispatch. This
can cause a deadlock if a timeout occurs at the same time since
the Tomcat timeout thread has its own locking that permits only
one thread to do timeout or dispatch processing.
The fix reduces the locking to cover only the attempt to set the
DeferredResult but not the dispatching.
Issue: SPR-10485
This change should be the final piece in the puzzle to let SmartInstantiationAwareBeanPostProcessor's predictBeanType predict a FactoryBean-produced type, effectively as a semantic alternative to its postProcessBeforeInstantiation-related role.
Issue: SPR-10517
(cherry picked from commit bc3e585)
Spring 3.2.2 introduced a change to avoid closing the response stream
in HttpMessageConverters (SPR-10095). However, the InputStream of
resources being written, for example as part of a multi-part request
should be closed. This change ensures that.
Issue: SPR-10460
If type conversion turns an empty request parameter value (i.e. "") to
null, we should treat it as a missing value. By default the
ConversionService doesn't change empty strings and therefore one must
explicitly convert them to null for example by registering a
StringTrimmerEditor with emptyAsNull=true.
Issue: SPR-10402
A recent change in FormTag to prepend the context and servlet paths if
not present, causes issues when used in portlet applications.
This change introduces a servletRelativeAction form tag attribute that
must be used for the context and servlet paths to be prepended.
Issue: SPR-10382
Previously ContentNegotiationManager continued with the next
ContentNegotiationStrategy only if the current one returned an empty
list. Now it also does that if the current ContentNegotiationStrategy
returns "*/*". Since the absence of an Accept header and "*/*" have
the same meaning, this allows a default content type to be used in
either case.
Issue: SPR-10513
@InitBinder and @ModelAttribute methods in @ControllerAdvice classes
are now invoked first, allowing any such methods in the @Controller
class to override them.
Issue: SPR-10419
HibernateJpaDialect's HibernateConnectionHandle does not call close() for Hibernate 4.x anymore, since on 4.2, the exposed Connection handle isn't a "borrowed connection" wrapper but rather the actual underlying Connection - with a close() call immediately returning the Connection to the pool and making the local handle invalid for further use within the transaction.
Issue: SPR-10395
Use LinkedHashMaps/Sets wherever exposed to users, and code tests defensively in terms of expected Map/Set ordering. Otherwise, there'll be runtime order differences between JDK 7 and JDK 8 due to internal HashMap/Set implementation differences.
Issue: SPR-9639
(cherry picked from commit 9c09a0a)
In particular, avoid accidental usage of ASM for core JDK types - which will fail in case of a new bytecode version in the JDK, even if the application itself has been compiled with an earlier bytecode target.
Issue: SPR-10292
(cherry picked from commit d3a4068)
Rework the reference documentation to better distinguish the differences
between @Bean methods used in @Comonent vs @Configuration classes. The
'Using the @Bean annotation' section now only covers concepts applicable
when using @Bean methods in @Configuration _or_ @Component classes.
Information only applicable to @Configuration classes has been moved to
a new 'Using the @Configuration annotation' section.
An additional sidebar section attempts to explain the differences
between the two approaches.
Issue: SPR-9425
Also, RequestBindingInterceptor now obtains HttpServletRequest from locally passed-in request handle and delegates to buildRequestAttributes as well now.
Issue: SPR-10342
Just AsyncAnnotationBeanPostProcessor switches "beforeExistingAdvisors" to "true" by default. So effectively, MethodValidation/PersistenceExceptionTranslationPostProcessor apply after existing advisors by default again, fixing the 3.1->3.2 regression.
Issue: SPR-10309
Assuming reference comparisons are much quicker than checking
likely-nested logger levels, perform the former first.
Also, since the reference can match only one of the instances,
use "else if" to short-circuit the search.
The problem was that clocks go forward *at* 2am, so
2am doesn't exist once a year. Users might be surprised
that their cron trigger doesn't go off one night, but that
is arguably correct (and what happens now). The test can be
modified if we decide to change the trigger behaviour.
Previously the methodParameter array field was initialized lazily since
it requires reflection. However, in practice the field is always used
and there is not much benefit from the lazy initialization.
In Spring Framework 3.2, the methodParameter field was copied when a
new HandlerMethod instance (with the resolved bean) is created for
performance reasons. That introduced a synchronization issue since
the lazy initialization was not synchronized.
Issue: SPR-10365
This commit reformats the testing chapter (and adds minor polishing
changes) in order to avoid massive merge diffs in upcoming commits.
Issue: SPR-10357
Check for an empty fragment in UriComponentsBuilder.fromUriString(...)
to prevent the invocation of fragment(...).
Previously, UriComponentsBuilder.fromUriString(...) threw an exception
in the case of an empty fragment being provided (e.g. /example#).
Issue: SPR-10363
MockServletContext.getMimeTypes now returns null if the Java Activation
Framework returns "application/octet-stream", which is the default
media type it returns if the mime type is unknown. This enforces the
contract for ServletContext.getMimeTypes (return null for uknown mime
types) but does mean "application/octet-stream" cannot be returned.
Issue: SPR-10334
Prior to this commit the Spring TestContext Framework supported creating
only flat, non-hierarchical contexts. There was no easy way to create
contexts with parent-child relationships.
This commit addresses this issue by introducing a new @ContextHierarchy
annotation that can be used in conjunction with @ContextConfiguration
for declaring hierarchies of application contexts, either within a
single test class or within a test class hierarchy. In addition,
@DirtiesContext now supports a new 'hierarchyMode' attribute for
controlling context cache clearing for context hierarchies.
- Introduced a new @ContextHierarchy annotation.
- Introduced 'name' attribute in @ContextConfiguration.
- Introduced 'name' property in ContextConfigurationAttributes.
- TestContext is now aware of @ContextHierarchy in addition to
@ContextConfiguration.
- Introduced findAnnotationDeclaringClassForTypes() in AnnotationUtils.
- Introduced resolveContextHierarchyAttributes() in ContextLoaderUtils.
- Introduced buildContextHierarchyMap() in ContextLoaderUtils.
- @ContextConfiguration and @ContextHierarchy may not be used as
top-level, class-level annotations simultaneously.
- Introduced reference to the parent configuration in
MergedContextConfiguration and WebMergedContextConfiguration.
- Introduced overloaded buildMergedContextConfiguration() methods in
ContextLoaderUtils in order to handle context hierarchies separately
from conventional, non-hierarchical contexts.
- Introduced hashCode() and equals() in ContextConfigurationAttributes.
- ContextLoaderUtils ensures uniqueness of @ContextConfiguration
elements within a single @ContextHierarchy declaration.
- Introduced CacheAwareContextLoaderDelegate that can be used for
loading contexts with transparent support for interacting with the
context cache -- for example, for retrieving the parent application
context in a context hierarchy.
- TestContext now delegates to CacheAwareContextLoaderDelegate for
loading contexts.
- Introduced getParentApplicationContext() in MergedContextConfiguration
- The loadContext(MergedContextConfiguration) methods in
AbstractGenericContextLoader and AbstractGenericWebContextLoader now
set the parent context as appropriate.
- Introduced 'hierarchyMode' attribute in @DirtiesContext with a
corresponding HierarchyMode enum that defines EXHAUSTIVE and
CURRENT_LEVEL cache removal modes.
- ContextCache now internally tracks the relationships between contexts
that make up a context hierarchy. Furthermore, when a context is
removed, if it is part of a context hierarchy all corresponding
contexts will be removed from the cache according to the supplied
HierarchyMode.
- AbstractGenericWebContextLoader will set a loaded context as the
ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE in the MockServletContext when
context hierarchies are used if the context has no parent or if the
context has a parent that is not a WAC.
- Where appropriate, updated Javadoc to refer to the
ServletTestExecutionListener, which was introduced in 3.2.0.
- Updated Javadoc to avoid and/or suppress warnings in spring-test.
- Suppressed remaining warnings in code in spring-test.
Issue: SPR-5613, SPR-9863
Update ResourcesBeanDefinitionParser to use ensure that location
attribute values remain in the order that they are specified. The
order was inadvertently changed in commit 3838d159f3 due to the use
of StringUtils.commaDelimitedListToSet which sorts items.
Issue: SPR-10355
* 3.2.x: (111 commits)
Fix FreeMarker form checbox macro generated names
Fix DefaultMockMvcBuilder fluent API generic type
Catch IAE when parsing content type
Update @RequestParam javadoc
Fix AntPathMatcher rule for combining with extensions
DefaultLobHandler etc
Minor javadoc updates
Deprecated OracleLobHandler in favor of DefaultLobHandler for the Oracle 10g driver and higher
Added "createTemporaryLob" flag to DefaultLobHandler, using JDBC 4.0's createBlob/Clob mechanism
Add Castor XSD information to reference docs
Do not use Servlet 3.0 API in doOptions()
Cache target type per bean definition and allow for specifying it in advance
Mentioning JDBC 4's unwrap method for obtaining the native connection now
LazyConnectionDataSourceProxy catches setReadOnly exception analogous to DataSourceUtils
Refined predictBeanType's typesToMatch check for FactoryBeans
Fix minor javadoc typos
Fix incorrect closing <web-app> tag in MVC docs
Fixed minor typo
Suppress warnings for resource leaks
Update spring-test re: deprecated queryForInt()
...
In Spring 3.2 a fix was implemented for all Spring Freemarker form
macros so that generated form input fields have valid bracketless IDs.
In the fix a regression was introduced manifesting in formCheckbox
macro no longer generating appropriate names for checkbox and hidden
input field.
This change fixes mentioned regression issue.
Issue: SPR-8732
Changed upper bound of generic parameter for DefaultMockMvcBuilder from
MockMvcBuilder to DefaultMockMvcBuilder to allow for ongoing method
chaining in the fluent API style.
Issue: SPR-10277
Before this fix AntPathMatcher had a special rule for combining
patterns with wildcards and extensions as follows:
"/*.*" + "/*.html" => "/*.html"
This change ensures this rule never applies if the first pattern
contains URI variables.
Issue: SPR-10062
Update the Spring OXM reference documentation to include changes
introduced in CastorMarshaller, specifically around CastorMarshaller
XSD configuration.
Issue: SPR-8509
Refactor FrameworkServlet.doOptions() to capture the "Allow" header
by using a HttpServletResponseWrapper.
Prior to this commit the HttpServletResponse.getHeader() method was
used which is only available in Servlet 3.0 environments.
Issue: SPR-10341
Inner beans are not prototype beans as, in contrast to what is
documented in the section for prototype beans, the inner bean does
get destruction callbacks applied.
Issue: SPR-10311
Previously we had restored the whitespace for *.aj files in 6888a6f28
to avoid a but in aspectj.
We have updated to the latest version of apsectj and restored the
changes in commit 6888a6f28 which included a significant cleanup of
whitespace.
Issue: SPR-10208
This commit introduces TestGroup#JMXMP and adds assumptions to related
tests accordingly. These tests require the jmxoptional_remote jar on the
classpath, and are run nightly in the SPR-PERF build.
Issue: SPR-8089
This commit lays the groundwork for introducing TestGroup#JMXMP and
related assumptions in select JMX-related tests in a subsequent commit;
JUnit assumptions require JUnit 4+ to function properly, so the entire
AbstractMBeanServerTests hierarchy must be moved over to JUnit 4+ style.
Issue: SPR-8089
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
The following changes have been made to the JDT UI prefs to conform to
existing conventions throughout the codebase:
- always favor .* syntax for static imports
- always list static imports last
Re-run `gradle eclipse` and refresh projects within Eclipse to make
this change take effect.
Update gradle MergePlugin to use the 'project.sourceSets.main.output'
for jar content rather than 'project.jar.source'. This prevents
superfluous MANIFEST.MF files from appearing in the merged jar.
Issue: SPR-10324
Update StringToEnumConverterFactory to search superclasses until
Class.isEnum() returns true. This allows conversion when the
enum class is obtained from the enum value:
public static enum SubFoo {
BAR { String s() { return "x"; } };
abstract String s();
}
conversionService.convert("BAR", SubFoo.BAR.getClass())
This fix is particularly important when converting collections of
enums.
Issue: SPR-10329
Deprecate HttpStatus.MOVED_TEMPORARILY in favor of HttpStatus.FOUND
since HttpStatus.valueOf(302) will always return FOUND.
The name of the 302 status code was changed between HTTP 1.0 and
HTTP 1.1 but the underlying meaning remains the same.
Issue: SPR-10300
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
Before this change the presence of path params (e.g. "/foo;q=1/bar")
expected the request mapping to contain a URI variable in the place of
semicolon content (e.g. either "/{foo}/bar" or "/{foo};{fooParams}").
The change ensures path params are ignored in @RequestMapping patterns
so that "/foo/bar" matches to "/foo;q=1/bar" as well as
"/foo;q=1;p=2/bar".
Along with this change, the RequestMappingHandlerMapping no longer
defaults to having semicolon content removed from the URL, which means
@MatrixVariable is supported by default without the need for any
further configuration.
Issue: SPR-10234
Add setOutputStreaming on SimpleClientHttpRequestFactory to allow the
disabling of 'output streaming' mode on the underlying connection so
that authentication and redirection can be handled automatically.
Issue: SPR-9617
Update reference guide to include a note about the use of
HttpPutFormContentFilter in combination with @RequestBody
MultiValueMap and HttpEntity.
Issue: SPR-8415
Change the org.apache.tiles.request.servlet.ServletRequest created
in TileView.checkResource to include the HttpServletRequest. This
is required when using a TilesConfigurer with useMutableTilesContainer
set to true. Without a HttpServletRequest the getRequestScope() method
will always return null causing exceptions in the CachingTilesContainer
class.
Unfortunately the checkResource method does not provide access to the
HttpServletRequest so it must be obtained via the RequestContextHolder
thread-local.
Issue: SPR-10223
Change JodaTimeFormatterRegistrar and DateFormatterRegistrar to only
register converters for the Date and Calendar types when a global format
has been defined. This means that the ObjectToObject converter will
handle String->Date conversion using the deprecated Date(String)
constructor (as was the case with Spring 3.1).
Issue: SPR-10105
Prior to this commit several HTTP classes made use of FileCopyUtils
when reading from or writing to streams. This has the unfortunate
side effect of closing streams that should really be left open.
The problem is particularly noticeable when dealing with a
FormHttpMessageConverter that is writing a multi-part response.
Relevant HTTP classes have now been refactored to make use of a new
StreamUtils class that works in a similar way FileCopyUtils but does
not close streams.
The NonClosingOutputStream class from SimpleStreamingClientHttpRequest
has also been refactored to a StreamUtils method.
Issue: SPR-10095
Update HierarchicalUriComponents.toUri() to only prepend a missing '/'
when the scheme, user info, host or port are specified. This makes
the toUri() method behave in the same way as .toUriString() and allows
relative URIs to be created.
Issue: SPR-10231
Effectively, AbstractTransactionAspect got refactored into around advice, reusing former TransactionInterceptor code which now lives in slightly generalized form in TransactionAspectSupport, and using a workaround for rethrowing checked exceptions.
Issue: SPR-9268
* 3.2.x:
Promote use of @PostConstruct and @PreDestroy
@Scheduled provides String variants of fixedDelay, fixedRate, initialDelay for placeholder support
Further preparations for 3.2.2
@Scheduled provides String variants of fixedDelay, fixedRate, initialDelay for placeholder support
Folded a FactoryBean-specific check into predictBeanType now
Fix Assert.instanceOf exception message
Allow for ordering of mixed AspectJ before/after advices
Minor javadoc and source layout polishing
Fixed documentation for "depends-on" attribute
"depends-on" attribute on lang namespace element actually respected at runtime now
Allow for ordering of mixed AspectJ before/after advices
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 the exception message used when Assert.instanceOf fails such
that it expects the provided message to end with '.'. This reverts
commit 5874383ef0 which caused the
implementation to be at odds with the JavaDoc and the previous
release.
The updated code also has the benefit of protecting against a null
message.
Issue: SPR-10269
* 3.2.x:
Preparations for 3.2.2
Marked spring-web module as 'distributable' in order for session replication to work on Tomcat
SQLErrorCodeSQLExceptionTranslator tries to find SQLException with actual error code, looping through the causes.
Fixed setFavorPathExtension delegation code
Added ContentNegotiationManager(Collection<ContentNegotiationStrategy>) constructor
ConfigurationClassPostProcessor allows for overriding of scoped-proxy bean definitions
Limit auto grow collection size when using SpEL
Improve presentation of code blocks in Javadoc
Polish @Configuration javadoc
Update Quartz documentation to use FactoryBeans
Support 'unless' expression for cache veto
Provide an additional constructor on SpelParserConfiguration that can
be used to limit the maximum size that a collection will auto grow when
being accessed via a SpEL expression.
This constraint is particularly useful when SpEL is used with data
binding as it prevents a malicious user from crafting a request that
causes OutOfMemory exceptions.
Issue: SPR-10229
Update examples for Quartz scheduling to use SimpleTriggerFactoryBean
and CronTriggerFactoryBean instead of SimpleTriggerBean and
CronTriggerBean.
Issue: SPR-10209
Allow @Cachable, @CachePut and equivalent XML configuration to provide
a SpEL expression that can be used to veto putting an item into the
cache. Unlike 'condition' the 'unless' parameter is evaluated after
the method has been called and can therefore reference the #result.
For example:
@Cacheable(value="book",
condition="#name.length < 32",
unless="#result.hardback")
This commit also allows #result to be referenced from @CacheEvict
expressions as long as 'beforeInvocation' is false.
Issue: SPR-8871
This commit improves the "Spring Test Dependencies" section of the 3.2
migration guide by correctly explaining that Hamcrest Core is now a
required transitive dependency of JUnit.
Issue: SPR-10251
Previously the maven dependencies were specified in an arbitrary order
which made comparing the poms against other versions difficult.
This commit sorts the dependencies by scope, group id, and then
artifact id.
This commit fixes a typo in the "New Features and Enhancements in Spring
Framework 3.2" chapter of the reference manual. Specifically,
ContentNegotiationStrategy is now spelled correctly.
Ensure that merge projects do not downgrade the compile time
dependencies of the projects that they are merged into.
This commit restores the scope of the following dependencies which
were inadvertently changed between Spring 3.2.0 and 3.2.1:
spring-orm
-> spring-tx
-> spring-jdbc
spring-webmvc
-> spring-context
-> spring-web
spring-test
-> spring-webmvc
Issue: SPR-10218
* springsource/3.2.x: (143 commits)
Remove eclipse project specific Javadoc settings
Increment version to 3.2.2.BUILD-SNAPSHOT
Release version 3.2.1.RELEASE
Tweak gradle generated eclipse meta-data
Completed changelog entries for 3.2.1
Avoid UnsupportedOperationEx. with active SecurityManager
Made EncodedResource based variant public; consistently detect XML properties across all variants
Added note on thread safety to TypeConverter and SimpleTypeConverter javadoc
Change merge.into project dependencies to provided
Final preparations for 3.2.1
Polishing
Removed pre-JDK-1.5 checks
ResourcePropertyResource accepts EncodedResource for properties files with a specific encoding
Updated resolvePath javadoc to reflect Environment-based placeholder resolution
DisposableBeanAdapter detects "shutdown" as a destroy method as well (for EHCache CacheManager setup)
Added further MySQL error code for DataIntegrityViolationException
ThreadPoolExecutorFactoryBean exposes "createExecutor" method for custom ThreadPoolExecutor subclasses
MBeanInfoAssembler impls expose actual method parameter names if possible
Suppress serialization warning
Allow nulls with multiple embedded value resolvers
...
Remove Javadoc settings from generated eclipse meta-data. Unfortunately
eclipse provides too many false warnings due to the fact that @Link and
@See tags in Spring often refer modules to which they cannot directly
depend.
- Change output folders to /bin/main and /bin/test. This prevents
'gradle clean' from breaking eclipse.
- Update copyright header for new files to '2002-2013'
Change 'compile' dependencies to 'provided' for projects that are
merged into other projects. This seems to prevent '-sources' and
'-javadoc' jars from appearing on the classpath which can break
javadoc generation.
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
Add a static factory method that can be used to create an array
TypeDescriptor with a specific element type. Allows array types
with generic elements to be constructed.
Issue: SPR-9792
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
JDK 5 introduced an XML-based properties file syntax. This commit
ensures that when such files are supplied as the underlying resource
for a ResourcePropertySource instance, they are routed appropriately
to Properties#loadFromXML as opposed to Properties#load.
Issue: SPR-9896
ConfigurableWebEnvironment was introduced in 3.2.0.M1 with SPR-9439 in
order to break a cyclic dependency. At the same time, certain signatures
such as AbstractRefreshableWebApplicationContext#getEnviroment and
GenericWebApplicationContext#getEnvironment were updated to take
advantage of covariant return types and return this newer, more narrow
type and providing cast-free calls to ConfigurableWebEnvironment methods
where necessary. Similar changes were made to HttpServletBean in
3.2.0.M2 with SPR-9763.
Narrowing #getEnvironment signatures in this fashion required enforcing
at the #setEnvironment level that any Environment instance provided
(explicitly or via the EnvironmentAware callback) must be an instance of
ConfigurableWebEnvironment. This is a reasonable assertion in typical
web application scenarios, but as SPR-10138 demonstrates, there are
valid use cases in which one may want or need to inject a non-web
ConfigurableEnvironment variant, e.g. during automated unit/integration
testing.
On review, it was never strictly necessary to narrow #getEnvironment
signatures, although doing so did provided convenience and type safety.
In order to maintain as flexible and backward-compatible an arrangement
as possible, this commit relaxes these #getEnvironment signatures back
to their original, pre-3.2 state. Namely, they now return
ConfigurableEnvironment as opposed to ConfigurableWebEnvironment, and in
accordance, all instanceof assertions have been removed or relaxed to
ensure that injected Environment instances are of type
ConfigurableEnvironment.
These changes have been verified against David Winterfeldt's Spring by
Example spring-rest-services project, as described at SPR-10138.
Issue: SPR-10138, SPR-9763, SPR-9439
For testing purposes in which an Environment implementation is required
but a ConfigurableEnvironment is not desirable.
All methods are no-ops and return null, therefore NPEs are likely.
Update JodaTimeConverters in include support for Date to String
conversion.
The JodaTimeFormattingTests and DateFormattingTests have been extended
to ensure that Date to String conversion is supported with or without
Joda.
Issue: SPR-10198
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)
The removal of whitespace to the *.aj files made in 1762157 cause
NoSuchMethodError for code compiled against previous versions of
spring-aspects due to a bug in AspectJ (see SPR-10178 for details).
This commit reverts all the whitespace changes made in 1762157 which
resolves the NoSuchMethodErrors.
Issue: SPR-10178
An expectation such as content().contentType(MediaType.TEXT_PLAIN)
fails if the actual media type contains a charset or another parameter.
A new method allows comparing the media type and subtype only via
content().contentTypeCompatibleWith(MediaType.TEXT_PLAIN).
Issue: SPR-10165
The Validation chapter now includes information on combining JSR-303
Bean Validation with additional Spring Validator's that don't require
the use of annotations.
Issue: SPR-9437
Update ReflectivePropertyAccessor to search for fields on super classes
and implemented interfaces.
Although the javadoc Class.getFields() implies that all public fields
of class should be returned SpelReproTests demonstrates that this is
not always the case.
Issue: SPR-10125
Fix SpEL expression parser and tokenizer to provide better exceptions
when dealing with operations that expect two operands. For example,
prior to this commit the expression '/foo' would throw a NPE due
to missing operands to the left of '/'.
Issue: SPR-10146
- Polished Javadoc for isAnnotationDeclaredLocally() and
isAnnotationInherited().
- Removed unnecessary call to Arrays.asList() in
isAnnotationDeclaredLocally().
This commit fixes the copyright year for changes made in commit
5b147bfba8. In addition, method names
have been changed to reflect the semantic changes made in that same
commit.
Revert ReflectivePropertyAccessor changes from 107fafb and instead
consider all methods when resolving properties. Methods are now
sorted such that non-bridge methods are considered before bridge
methods.
Issue: SPR-10162
DataBinder now allows registering additional Validator instances.
This may be useful when adding a Spring Validator to a globally
registered JSR-303 LocalValidatorFactoryBean.
Issue: SPR-9436
Update gradle to generate the following project specific eclipse
settings:
- Java formatting
- Cleanup options
- Warning settings
- Code template with copyright header
- WTP module meta-data
In addition this commit changes the eclipse project .classpath file
to output test and main classes to different folders. This is required
to prevent eclipse WTP from packaging test classes into /WEB-INF/lib
jar files.
Issue: SPR-9518
- Now excluding *TestSuite classes from the JUnit test task.
- Renamed SpringJUnit4SuiteTests to SpringJUnit4TestSuite so that it is
no longer executed in the build.
- Reduced sleep time in various timing related tests.
# By Chris Beams (2) and others
* SPR-9990:
Refactor detect-split-packages Gradle plugin
Replace space indentation with tabs
Rework split package detection code
Example SplitPackageDetectorPlugin
Detect split packages at build time
- Use conventional plugin naming, i.e. "detect-split-packages" instead
of applying plugin based on fully-qualified class name
- Rename "diagnose" => "detect" consistently throughout plugin, task
and method names and generally refactor naming throughout to follow
"detect split packages" phrasing
- Add Javadoc to DetectSplitPackagesPlugin
- Improve error reporting when split packages are detected
Upon detecting one or more split packages, `detectSplitPackages` now
fails idiomatically, throwing a GradleException to signal task failure
(as opposed to the previous approach of using an assert assertion), and
the output reads as follows:
$ gradle detectSplitPackages
[...]
:buildSrc:build UP-TO-DATE
:detectSplitPackages FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':detectSplitPackages'.
> The following split package(s) have been detected:
- org.springframework.beans (split across spring-beans and spring-orm)
- org.springframework.core.env (split across spring-context and spring-core)
- DetectSplitPackagesTask now automatically attaches itself to `check`
task lifecycle if the enclosing project contains a `check` task
- DetectSplitPackagesTask adds itself to the 'Verification' task group,
ensuring that it shows up correctly in `gradle tasks` task listings
- packagesToScan now defaults to all subprojects; users may then
customize this by removing individual subprojects from the collection
Issue: SPR-9990
Previously aspects.gradle used the Gradle conventions for the source
and target compatibility. This means that unless the conventions were
updated the current JDK would be used for both source and target
compatibilty. Since an update to build.gradle changed to configure the
compileJava and compileTestJava tasks explicitly spring-aspects has
been compiled with JDK 7 compatibility.
This commit explicitly uses the source and target compatibility from
spring-core to ensure that aspects.gradle is kept up to date.
Issue: SPR-10161
Prior to this commit, the Gradle build configuration only executed
TestNG-based tests and effectively disabled all JUnit-based tests in the
spring-test module. Furthermore, TestNG-based tests were not properly
reported in Bamboo CI builds.
This commit ensures that both JUnit and TestNG tests are executed in the
Gradle build by defining a new testNG task within the spring-test
configuration. The test task now depends on the new testNG task.
Furthermore, the testNG task makes use of Gradle 1.3's support for
generating test reports for TestNG tests alongside reports for JUnit
tests. The net effect is that all tests are executed and reportedly
properly in Bamboo builds on the CI server.
- Enabled both JUnit and TestNG tests for the spring-test module.
- Corrected bugs in FailingBeforeAndAfterMethodsTests introduced in
commit 3d1b3868fe.
- Deleted the now obsolete SPR-9398.txt file.
Issue: SPR-9398
The fields returned from a RequestDataValueProcessor are now
written as hidden fields without a closing tag.
Before:
<input type="hidden" name="xxx" value="yyy"></input>
After:
<input type="hidden" name="xxx" value="yyy" />
Issue: SPR-10103
Update the gradle 'api' task to depend on the 'jar' task of all
subprojects. This intern ensures that the 'asmRepackJar' and
'cglibRepackJar' tasks run which is critical for JavaDoc
generation.
Allow packages to be split across projects which will be merged into a
single JAR file.
Make split package detection a dependency of the 'check' task. This
is idiomatic gradle as well as allowing the 'test' task (another
dependency of 'check') to be executed without split packages being
detected.
Omit the project spring-instructment-tomcat from the check on the basis
of SPR-10150.
Issues: SPR-9990, SPR-10150
Conflicts:
build.gradle
Split packages are a well-known anti-pattern for OSGi and a blocker for
Eclipse Virgo (which prevents split packages being accessed via its
Import-Library construct).
Split packages are also unhelpful with a traditional linear classpath
as a split package name does not uniquely identify the Spring framework
JAR from which it came, thus complicating problem diagnosis and
maintenance.
Juergen Hoeller supports this position in the following comment in
SPR-9990:
>FWIW, I generally find split packages a bad practice, even without
>OSGi in the mix. For the Spring Framework codebase, I consider a
>split-package arrangement a design accident that we want to detect
>in any case - and that we're willing to fix if it happened.
>
>I'm actually equally concerned about the source perspective: After
>all, we want a package to be comprehensible from a single glance
>at the project, not requiring the developer to jump into several
>source modules to understand the overall layout of a package.
Split packages have crept into Spring framework twice in recent months
- see SPR-9811 and SPR-9988. Currently, they are only detected once
the Spring framework has been converted to OSGi bundles and these
bundles have been tested with Eclipse Virgo.
This commit adds a build-time check for split packages to the Spring
framework build.
Issue: SPR-9990
Conflicts:
build.gradle
* cleanup-3.2.x: (37 commits)
Eliminate AJ @Async warning in test case
Update Apache license headers for moved files
Move namespace tests to root integration module
Fix several miscellaneous compiler/Eclipse warnings
Remove duplicate test resources
Fix warnings due to unused import statements
Update Apache license headers for affected sources
Remove duplicate test classes
Replace test beans with test objects
Polish test sourceSet dependencies
Add test dependencies sources for testCompile
Use unmodified 'version' when not on a topic branch
Enable execution of TestNG tests in spring-test
Polish support for topic branch-specific versions
Segregate add'l long-running and performance tests
Eliminate EBR dependencies and repository config
Skip creation of IDEA metadata for spring-aspects
Fix Eclipse compilation error in Gradle plugin
Polish build.gradle
Recursively add test dependencies
...
* cleanup-3.2.x:
Eliminate AJ @Async warning in test case
Update Apache license headers for moved files
Move namespace tests to root integration module
Fix several miscellaneous compiler/Eclipse warnings
Remove duplicate test resources
Fix warnings due to unused import statements
Update Apache license headers for affected sources
Remove duplicate test classes
Replace test beans with test objects
Polish test sourceSet dependencies
Add test dependencies sources for testCompile
* SPR-9431:
Eliminate AJ @Async warning in test case
Update Apache license headers for moved files
Move namespace tests to root integration module
Fix several miscellaneous compiler/Eclipse warnings
Remove duplicate test resources
Fix warnings due to unused import statements
Prior to this commit, ClassWithAsyncAnnotation#return5 forced an
unsuppressable warning in Eclipse, making it virtually impossible to
get to a zero-warnings state in the codebase.
The 'solution' here is simply to comment out the method and it's
associated test case. The 'declare warnings' functionality around
@Async is well-understood and has long been stable.
Also, the entire AnnotationAsyncExecutionAspectTests class has been
added to TestGroup#PERFORMANCE (SPR-9984), as opposed to just
asyncMethodGetsRoutedAsynchronously as it was previously, the
rationale being that all tests are actually timing dependent.
Issue: SPR-9431, SPR-9984
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
- Suppress an (intentional) AspectJ warning
- Remove unused imports
- Suppress a [hiding] warning
- Fix a generics warning related to extension of final types
Issue: SPR-9431
The files deleted in this commit existed in identical form in two places
within a given module; typically in src/test/java and
src/test/resources. The version within src/test/resources has been
favored in all cases.
This change was prompted by associated Eclipse warnings, which have now
been quelled.
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
Refactor spring-core tests to replace test beans from
'org.springframework.beans' with lighter test objects in
'org.springframework.tests.sample.objects'.
Remove all direct sourceSets.test.output dependencies and instead rely
on the 'test-source-set-dependencies' plugin.
This commit also updates the api JavaDoc task to ensure that
dependencies are not resolved too early.
* cleanup-3.2.x:
Enable execution of TestNG tests in spring-test
Polish support for topic branch-specific versions
Segregate add'l long-running and performance tests
Eliminate EBR dependencies and repository config
Skip creation of IDEA metadata for spring-aspects
Fix Eclipse compilation error in Gradle plugin
Polish build.gradle
Both JUnit- and TestNG-based tests are once again executed in the
spring-test module.
Note that two lines in FailingBeforeAndAfterMethodsTests had to be
commented out. See diff or `git grep 'See SPR-8116'` for details.
Issue: SPR-8116
- 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
Swap the following EBR-specific dependencies for their equivalents at
Maven Central:
- atinject-tck
- jaxb
- xmlbeans
Remove the /ebr-maven-external repository from the build script entirely
such that all dependencies are now resolved against a single repository:
http://repo.springsource.org/libs-release
Prior to this commit, the following compilation error presented itself
when importing buildSrc ('spring-build-src') into Eclipse:
Groovy:missing type for constructor call @ line 36, column 49.
This commit replaces the use of the diamond operator with typical
generics syntax in order to work around the problem. It is assumed that
the underlying problem is to do with the Groovy compiler in use. This
change ensures that any contributor / committer importing
spring-framework into Eclipse has a straightforward experience without
being required to tweak Groovy settings.
If selection of the correct Groovy compilation settings can be made
automatic, then we should of course feel free to use Java 7-style syntax
there in the future.
Note that this was *not* a problem when importing buildSrc into IDEA 12.
After this change ParameterContentNegotiationStrategy no longer allows
a null parameter name, ContentNegotiationManagerFactoryBean also
requires it.
Issue: SPR-10139
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.
Develop a gradle plugin to automatically update testCompile dependencies
to include the test source sets of project dependencies.
Allows the gradle build to more closely mirror the way that tests run
inside eclipse.
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
Prior to this change, SpEL was capable of handling getter methods for
property names having a lowercase first letter and uppercase second
letter such as:
public String getiD() { ... }
However, setters with the same naming arrangement were not supported,
e.g.:
public void setiD() { ... }
This commit ensures that setters and getters are treated by SpEL equally
in this regard, such that "iD"-style property names may be used anywhere
within SpEL expressions.
Issue: SPR-10122, SPR-9123
* cleanup-3.2.x: (21 commits)
Update Apache license headers for affected sources
Ignore performance-sensitive tests by default
Introduce 'spring-build-junit' subproject
Replace EasyMock with Mockito in test sources
Add @Override annotations to test sources
Update test source and target JDK compatibility
Update -Xlint compiler warning output
Fix various compiler warnings in spring-context
Fix "unnecessary @SuppressWarnings" warnings
Fix [rawtypes] compiler warnings
Fix [dep-ann] warnings with @Deprecated
Fix [cast] compiler warnings
Fix [serial] compiler warnings
Fix [varargs] compiler warnings
Fix warnings due to unused import statements
Replace <code> with {@code} throughout Javadoc
Fix various Javadoc warnings
Replace space indentation with tabs
Remove trailing whitespace in source files
Various updates to support IDEA
...
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
Introduce new 'spring-build-junit' subproject containing shared
JUnit utilities and classes to be used by other test cases. This
project is for internal use within the framework, and therefore
creates no artifacts to be published to any repository.
The initial code includes support for JUnit Assumptions that can
be used to determine when a test should run. Tests can be skipped
based on the running JDK version, logging level or based on specific
'groups' that have activated via a Gradle property.
It is intended that sources within the spring-build-junit project be
folded into spring-core/src/test/java, pending some Gradle work that
will facilitate sharing test output across subprojects; therefore this
commit should be seen as a temporary solution.
Issue: SPR-9984
"test" source and target compatibility has been upgraded to 1.7 except
where noted, allowing us to use 1.7 language features such as
diamond-style (<>) generics declarations, automatic resource management
and multi-catch. More importantly, we will be able to upgrade to 1.8
once it is available in order to make use of lambda expressions, etc in
our test cases.
IDE configurations must be relaxed to allow 1.7 across the board, as
neither Eclipse nor IDEA are clever enough to allow for different
language levels across production and test resources. See [1] for a
feature request on that front.
spring-oxm is a special case here, and has been pinned at 1.6
compatibility even for its test sources in order to avoid a class
verification error that JibX throws when encountering 1.7-level
bytecode [2].
Likewise with spring-orm, toplink encounters a similar class
verification error, so has been pinned to 1.6 for the time being.
When we remove the (already deprecated since 3.2) Toplink support
we can restore compatibility to 1.7.
[1]: http://youtrack.jetbrains.com/issue/IDEA-97814
[2]: http://jira.codehaus.org/browse/JIBX-465
Issue: SPR-10129
Enable output for the compiler warnings that have been eliminated so
far. 'rawtypes', 'deprecation', and 'unchecked' remain suppressed until
these warnings can be fully eliminated as well.
- 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
Previously the algorithm used by GenericConversionService to find
converters incorrectly searched for interfaces working up from the
base class. This caused particular problems with custom List
converters as as the Collection interface would be considered before
the List interface giving CollectionToObjectConverter precedence
over the custom converter.
The updated algorithm restores the class search order to behave in the
same way as Spring 3.1.
Issue: SPR-10116
Backport-Issue: SPR-10117
Backport-Commit: aa914497dc
Pick up fix for regression in version 0.2.3 that caused project-specific
images, e.g. diagrams not to be copied into the images/ folder, thereby
causing broken image links online and in the PDF.
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).
Previously buildSrc/src/main/groovy was a source folder within Eclipse.
This caused build errors due to missing dependencies for Gradle.
This commit removes buildSrc/src/main/groovy from the source folders
within Eclipse to prevent errors from being displayed.
This change upgrades the spring-framework build to AspectJ 1.7.1 to
ensure compatibility. We remain backward-compatible to at least AJ
1.6.12 (the previous version), and likely back to 1.6.7.
AJ 1.7 allows for weaving Java 7 bytecode, particularly with regard
to invokedynamic instructions, and furthermore makes improvements to
the aspectj language itself to allow users to take advantage of Java 7-
style language features within aspects. See [1] for details.
[1]: http://eclipse.org/aspectj/doc/released/README-170.html
Issue: SPR-10079
- 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
Prior to this change, aggregated javadoc has been written to an 'api'
dir and reference docs into a 'reference' dir. This shorter naming is
desirable, but is not compatible with historical naming under 3.1.x as
defined by the Ant+Ivy Spring Build.
For example, URLs are currently as follows:
http://static.springsource.org/spring-framework/docs/3.1.3.RELEASE/javadoc-apihttp://static.springsource.org/spring-framework/docs/3.1.x/javadoc-apihttp://static.springsource.org/spring-framework/docs/current/javadoc-api
Particularly with regard to the 'current' link, we do not want to
break this url scheme with the shortened 'api' directory naming. Of
course this compatibility can be preserved with symlinks, but this makes
the release process that much more complicated and fragile.
This commit ensures that the naming is 'javadoc-api' and
'spring-framework-reference', consistent with historical convention.
We can always add a symlinking scheme to add the shorter 'api' and
'reference' options after the fact if desired.
Added "clearCache()" method to CachingMetadataReaderFactory, for clearing the metadata cache once not needed anymore - in particular when the MetadataReaderFactory instance is long-lived. Also added "setMetadataReaderFactory" method to ClassPathScanningCandidateComponentProvider, analogous to ConfigurationClassPostProcessor.
This commit adds documentation to the "New Features and Enhancements in
Spring 3.2" section of the reference manual regarding new testing
features.
Issue: SPR-9941
This commit adds documentation for the following new features in the
Spring TestContext Framework within the Testing chapter of the reference
manual.
- @WebAppConfiguration and context caching
- WebDelegatingSmartContextLoader
- AnnotationConfigWebContextLoader
- GenericXmlWebContextLoader
- Loading a WebApplicationContext in integration tests
- ServletTestExecutionListener
- Testing request and session scoped beans
Issue: SPR-9864
This commit adds Javadoc documentation for the WebApplicationContext
testing support that was recently introduced in the Spring TestContext
Framework.
Issue: SPR-9864
Update tiles.xml files used with tests to reference tiles-config_3_0
instead of tiles-config_2_1 DTD.
Prior to this commit tiles based tests would fail when building
offline or behind a proxy server.
Previously it was cumbersome to associate data or behavior to a
DeferredResult because it was marked as final and had no extension
points.
Now DeferredResult is non-final which allows subclasses to associate
additional data and behavior to it.
Issue: SPR-10059
Previously the 'merge from' project's configurations exclude rules were
not used in the dynamically created 'merge into' project configurations.
This meant that the pom generation for 'merge into' project did not
exclude the dependencies from the 'merge from' project's configuration
excludes.
Now the exclude rules are copied into the dynamically created
'merge into' project's configurations.
Refactor the existing merge-artifacts script to a full Gradle plugin.
The new plugin uses a 'merge' extension in favor of Gradle 'ext'
configuration and can be applied to all projects in a multi-module
build.
Any project that defines a 'merge.into' project will now implicitly
receive a dependency to that project. Furthermore other projects
with a dependency on 'merge.into' will receive a direct project
link within the IDE. For example: 'spring-webmvc-tiles3'
is merged into 'spring-webmvc' and 'spring-test-mvc' depends
on 'spring-webmvc'. Within the IDE 'spring-test-mvc' will show
dependencies to both 'spring-webmvc' and 'spring-webmvc-tiles'.
Issue: SPR-10042
Replace existing 'optional' and 'provided' Spring specific build
extensions with a new Gradle propdeps-plugin. Optional and Provided
dependencies are now defined use dependency configurations.
The new plugin does not currently support the notion of optional
runtime dependencies. All optional dependencies are implicitly
part of the 'compile' scope. This is an intentional design decision
that aims to keep both the plugin and the build simple. Since optional
dependencies are non-transitive this restriction should not cause
any real problems for existing users. The only existing dependency
affected is 'commons-io' in the 'spring-beans' project, however, this
was an optional compile scope dependency in the previous Spring 3.1
release.
Both provided and optional dependencies are no longer exported from
generated eclipse .classpath files. This fixes several tests that
would previously fail when running within eclipse. The servlet-api
specific elements of ide.gradle are also no longer required.
Issue: SPR-9656, SPR-10070
Upgrade to the latest stable release of log4j. The previous 'jms'
and 'jmx' exclusions are not longer required since these have now
been marked as optional dependencies in the upstream POM.
Update all Gradle files to use a consistent style when specifying
dependencies. All dependencies are now specified using parentheses,
for example:
scope("group:artifat:version")
or scope(project(":projectname"))
When Spr9799XmlConfigTests and Spr9799AnnotationConfigTests were
created, there were issues with the classpath related to slf4j
dependencies that made it impossible for these classes to reside in the
spring-test module. Consequently, these tests were added to the
spring-test-mvc module. However, the issues with slf4j have since been
resolved in the Gradle build, and this commit therefore moves these test
classes to the spring-test module where they belong.
Issue: SPR-9799
This change introduces a new AllEncompassingFormHttpMessageConverter
class that adds JSON and XML converters for individual mime parts of
a multi-part request. The new converter is used in place of the
previously used XmlAwareFormHttpMessageConverter.
Issue: SPR-10055
The servlet spec treats any jar in WEB-INF/lib as a web fragment:
"A plain old jar file in the WEB-INF/lib directory with no web-
fragment.xml is also considered a fragment" (section 8.2.1)
This change adds a web-fragment.xml giving the web fragment an
explicit name, "spring_web", and indicating there is no need
to scan for Servlet annotations in the spring-web.jar itself
through metadata-complete=true.
This allows applications that choose to include only specific
web fragments, through the <absolute-ordering> element in web.xml
to also include the "spring_web" fragment, in order to enable scanning
for WebApplicationInitializer types.
tiles-core-3 brings in a dependency on jcl-overl-slf4 which causes
an slf4j delegation loop as explained at [1] when tests run inside
Eclipse. Other modules that depend on tiles-core like
(tiles-servlet, tiles-jsp) have also had the exclusion added since
they seem to bring it in as well.
[1] http://www.slf4j.org/codes.html#jclDelegationLoop
Prevously the FrameworkServlet created a new ServletRequestAttributes
instance for every request, unless the RequestContextHolder already
contained an instance whose type is not ServletRequestAttributes.
The main intent was that if RequestContextHolder contains a
PortletRequestAttributes, it should be left in place.
This change does an "instanceof" check against the request in
RequestContextHolder instead of an "equals" check on the type.
It still leaves PortletRequestAttributes in place but also allows
the previous request to be any sub-class of ServletRequestAttributes.
Issue: SPR-10025
- Deleted unused imports.
- Switched from junit.framework.Assert to org.junit.Assert, since the
former is deprecated as of JUnit 4.11.
- Suppressed warnings for continued deprecated usage of
junit.framework.Assert.
Spring Framework 3.2 M2 added the ability to map requests using only
file extensions registered through the configured through a
ContentNeotiationManager, as opposed to allowing any file extension
(i.e. ".*"). The MVC namespace the MVC Java config automatically
register extensions such as ".json" and ".xml" depending on libraries
found on the classpath. That in turn causes issues in cases where
additional extensions are in use but not registered (e.g. ".html").
This change ensures that matching with registered file extensions only
works only if explicitly enabled through a property on
RequestMappingHandlerMapping.
Issue: SPR-10061, SPR-8474
Prior to this commit, executing an SQL script via
ResourceDatabasePopulator would fail if a statement in the script
contained a line comment within the statement.
This commit ensures that standard SQL comments (i.e., any text beginning
with two hyphens and extending to the end of the line) are properly
omitted from the statement before executing it.
In addition, multiple adjacent whitespace characters within a statement,
but outside a literal, are now collapsed into a single space.
Issue: SPR-10075
Prior to this commit, executing an SQL script with JdbcTestUtils would
fail if a statement in the script contained a line comment within the
statement.
This commit ensures that standard SQL comments (i.e., any text beginning
with two hyphens and extending to the end of the line) are properly
omitted from the statement before executing it.
In addition, multiple adjacent whitespace characters within a statement
but outside a literal are now collapsed into a single space.
Issue: SPR-9982
The @ModelAttribute javadoc now explicitly mentions that model content
is not available after an Exception is raised. This is a very common
question given that @ExceptionHandler methods are co-located with
@ModelAttribute and @RequestMapping methods.
Issue: SPR-10071
This commit upgrades the compile dependency on JUnit in the spring-test
module as well as the global test dependency on JUnit for the entire
test suite to 4.11 GA.
In addition, the spring-test module now depends on junit:junit instead
of junit:junit-dep since, as of JUnit 4.11, the "junit" Maven artifact
no longer inlines hamcrest-core.
Issue: SPR-10044
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
Replace the gradle dependency on aspectjrt with aspectjweaver since
aspectjrt is a subset of aspectjweaver and the full jar is required
by Spring. SPR-8896 fixed the original code issue, this change
just relates to the generated maven pom.
Issue: SPR-10072
Upgrade to docbook-reference-plugin v0.2.2 and remove custom xsl
styles in favor of plugin defaults. Modify some docbook source
files to work with newer style.
- Defined global slf4jVersion as '1.6.1' in the Gradle build.
- Replaced dependencies on slf4j-log4j12 with slf4j-jcl where possible;
however, spring-test-mvc still depends on jcl-over-slf4j and
slf4j-log4j12 (see SPR-10070).
- Reenabled HibernateSessionFlushingTests.
- Verified that the following tests pass in the Gradle build and within
Eclipse:
- HibernateSessionFlushingTests
- HibernateTransactionManagerTests (Hibernate 3)
- HibernateTransactionManagerTests (Hibernate 4)
- RequestResponseBodyMethodProcessorTests
Issue: SPR-9421, SPR-10066
The previous commit by Juergen Hoeller upgraded spring-orm's Hibernate 3
dependency to 3.3.2.GA, and this commit removes the now unnecessary
dependency on org.hibernate:hibernate-cglib-repack:2.1_3.
Issue: SPR-10066
The Javadoc in MockMvcClientHttpRequestFactoryTests had been copied and
pasted from WebAppResourceTests. This commit updates the documentation
in MockMvcClientHttpRequestFactoryTests to reflect what the tests do.
This commit ensures that EasyMock version 2.5.2 is used consistently
across the test suite. This applies to both the easymock and
easymockclassextension artifacts. Using the same version for both of
these artifacts helps to better align us for a future upgrade to
EasyMock 3.0 since the Class Extension artifact is deprecated in 3.x
releases of the library.
Issue: SPR-10069
This commit relocates recently introduced web artifacts in the
TestContext framework to the ~.test.context.web package and renames some
classes for consistency with the existing code base.
- introduced package-info.java in the web package.
- ServletTestExecutionListener now extends
AbstractTestExecutionListener instead of implementing
TestExecutionListener.
- relocated AbstractGenericWebContextLoader,
AnnotationConfigWebContextLoader, XmlWebContextLoader, and
WebDelegatingSmartContextLoader to the web package.
- renamed XmlWebContextLoader to GenericXmlWebContextLoader for
consistency with GenericXmlContextLoader.
- changed the visibility of AbstractDelegatingSmartContextLoader and
AnnotationConfigContextLoaderUtils to public.
Issue: SPR-10067
The tiles-request-servlet-wildcard contained only one class that is an
implementation of the tiles-request ServletApplicationContext using a
Spring ApplicationContext to look up resources. It makes sense for this
class to be part of the Spring Tiles 3 integration.
Issue: SPR-10054
Previously when running the tests for spring-web, spring-webmvc,
spring-test-mvc, and spring-orm there were possible collissions in the
classpath due to the fact that each had its own copy of the web.Mock*
classes in it. This causes uncertainty for which class the code was
running against. Furthermore, the maintance of keeping the copies up to
date was tedious.
Now there are two copies of the web.Mock* classes. The ones that exist
in spring-test main sources and a copy that supports servlet 3 within
spring-web test sources. The copy in spring-web test sources has been
moved to a new package to avoid having the classes exist twice on the
classpath within Eclipse.
Previously CallableProcessingInterceptor and
DeferredResultProcessingInterceptor did not have support for capturing
the state of the original Thread just prior to processing. This made it
difficult to transfer the state of one Thread (i.e. ThreadLocal) to the
Thread used to process the Callable.
This commit adds a new method to CallableProcessingInterceptor and
DeferredResultProcessingInterceptor named beforeConcurrentHandling
which will be invoked on the original Thread used to submit the Callable
or DeferredResult. This means the state of the original Thread can be
captured in beforeConcurrentHandling and transfered to the new Thread
in preProcess.
Issue: SPR-10052
Refactor MBean Server reset code from MBeanServerFactoryBeanTests
and reuse in AdvisedJRubyScriptFactoryTests and
AbstractMBeanServerTests.
Issue: SPR-9288
The name MvcAsyncTask is misleading because the class is part of Spring
Web as apposed to Spring MVC. This is also inconsistent with the other
async classes which use Web instead of Mvc.
This commit changes MvcAsyncTask to WebAsyncTask making it more
consistent with the jar it is found in and the other async classes.
Issue: SPR-10051
# By Rob Winch
# Via Rob Winch
* gradle-1116:
Make GRADLE-1116 workaround more generic
# By Rob Winch
* spring-test-mvc-classpath:
Fix spring-test-mvc Eclipse classpath
Previously the workaround for GRADLE-1116 only worked for the
merge-dist.gradle projects
Now the workaround is more generic and fixes errors that have since
been introduced when performing a fresh import into Eclipse.
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
Previously reflection was required when interacting with Hibernate 4 in
order to support both Hibernate 3 and Hibernate 4 since there were
non-passive changes in the APIs. Now that the Spring build uses Gradle
it is trivial to support multiple Hibernate versions.
This commit removes the reflection usage in orm.hibernate4.* by
creating a spring-orm-hibernate4 module that uses
gradle/merge-artifacts.gradle to build a single artifact but keep
distinct classpaths.
Issue: SPR-10039
This change upgrade the framework to consume the newly-published
docbook-reference-plugin version 0.2.1 containing a maximum width
for the HTML reference guide.
Prior to this change, the INSTANCE constant one could refer to on
AnnotationAwareOrderComparator actually referred to the constant
declared in the OrderAwareComparator superclass. Thus
AnnotationAwareOrderComparator#INSTANCE did not actually return an
AnnotationAwareOrderComparator but an OrderAwareComparator instead. This
commit introduces a dedicated constant on AnnotationAwareOrderComparator
to avoid this glitch.
Issue: SPR-10038
This change upgrade the framework to consume the newly-published
docbook-reference-plugin version 0.2.0, which includes among other
improvements a revamped CSS approach designed to look as similar
as possible to the way markdown files are rendered by GitHub.
See associated commit [1] at SpringSource's gradle-plugins repo for
further details.
Issue: SPR-10036
[1]: https://github.com/SpringSource/gradle-plugins/commit/b209c350ed76c10815815ab320c2379e8de3fec9
Restore the custom title page of the reference manual in order to
remove the large list of authors on the first page.
Note: This change will require updating to version 0.1.7 of the
docbook-reference-plugin when it is released.
Issue: SPR-10008
Remove all xsd versions from the reference manual samples in favor of
"versionless" XSDs. For example, spring-beans-3.0.xsd becomes
spring-beans.xsd
Issue: SPR-10010
Prior to this commit many imagedata elements were duplicated in
order to configure PDF sizes. Since HTML generation is configured
to ignore image scaling altogether this was unnecessary duplication.
Issue: SPR-10033
Convert all docbook XML files to well-formed docbook 5 syntax:
- Include xsi:schemaLocation element for tools support
- Convert all id elements to xml:id
- Convert all ulink elements to link
- Simplify <lineannotation> mark-up
- Fix misplaced </section> tags
- Fix <interface> tags to <interfacename>
- Cleanup trailing whitespace and tabs
Issue: SPR-10032
Since web applications declaring a Servlet 2.3 web.xml become really rare now, we're finally deprecating Spring's own ExpressionEvaluationUtils class. As a consequence, we're also setting "springJspExpressionSupport" to false by default, avoiding the potential double EL evaluation problem on pre-Servlet-3.0 containers.
Issue: SPR-5308
Since web applications declaring a Servlet 2.3 web.xml become really rare now, we're finally deprecating Spring's own ExpressionEvaluationUtils class. As a consequence, we're also setting "springJspExpressionSupport" to false by default, avoiding the potential double EL evaluation problem on pre-Servlet-3.0 containers.
Issue: SPR-5308
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
Since web applications declaring a Servlet 2.3 web.xml become really rare now, we're finally deprecating Spring's own ExpressionEvaluationUtils class. As a consequence, we're also setting "springJspExpressionSupport" to false by default, avoiding the potential double EL evaluation problem on pre-Servlet-3.0 containers.
Issue: SPR-5308
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
The new jdiff task generates a report of API differences between the
current version (i.e. the value of `version` in gradle.properties) and
any older version of the framework, as specified by -DOLD_VERSION at
the command line, or defaulting to `previousVersion` in
gradle.properties.
Running the command requires a separate clone directory pinned to the
desired old version, as specified by -DOLD_VERSION_ROOT at the command
line. This creates challenges from a build automation perspective,
largely because Gradle doesn't (yet) have APIs for working with Git.
This task may be further automated and included in nightly CI runs, but
in the meantime, a number of reports back to 3.1.3.RELEASE have been
generated manually and uploaded to [1], where one can now find the
following entries in the directory listing:
- 3.1.3.RELEASE_to_3.2.0.RC1
- 3.2.0.M1_to_3.2.0.M2
- 3.2.0.M2_to_3.2.0.RC1
- 3.2.0.RC1_to_3.2.0.BUILD-SNAPSHOT
Ideally, the final entry there would be kept up-to-date on a daily
basis - again we may revisit doing so in the future. Going forward,
reports will be generated and uploaded manually on an as needed basis
and as part of the release process.
The goal of these reports are as follows:
- to ease the process of ensuring backward compatibility
- to aid in code reviews, particularly when reviewing large pull
requests
- to ease the process of creating migration guides for project
maintainers, i.e. to help us remember what's changed
- to allow ambitious end-users to discover what's been changing at the
API level without without needing to wait for detailed "what's new in
version X" and/or migration guide documentation
See documentation in jdiff.gradle for usage details.
Note that the jdiff-1.1.1 distribution as downloaded from [2] has been
added wholesale to the source tree under gradle/jdiff instead of
uploading JDiff jars to repo.springsource.org as we would normally do.
This is due to some unfortunate limitations in the implementation of the
jdiff ant task that require a phisical JDIFF_HOME directory. Checking in
the jars and various resources represents the simplest and most
pragmatic solution to this problem, though ambitious contributors are
free to do what's necessary to arrive at a more elegant arrangement.
[1]: http://static.springframework.org/spring-framework/docs
[2]: http://sourceforge.net/projects/javadiff/files/latest/download
Issue: SPR-9957
Previously the publish-maven.gradle only supported having a single
artifact be marked as optional or provided. This causes problems now
that we are building modules that support multiple versions of an
artifact. For example, we compile against two versions of Tiles
artifacts with identical names, both of which need to be marked
optional.
This updates publish-maven.gradle to find all the artifacts and mark
them as optional as apposed to the first entry.
The change to support generic @RequestBody arguments introduced in
3.2 M2 also introduced a regression in reading arguments that are
type variables. This change fixes the issue.
Issue: SPR-9964
Update SpEL boolean operators to always call the ConversionService
for null values. Primarily to allow null values to be treated as
false by overriding GenericConversionService.convertNullSource().
Issue: SPR-9445
Replace reference to aspectjrt.jar with aspectjweaver.jar since
aspectjrt is a subset of aspectjweaver and the full jar is required
by Spring.
Issue: SPR-8896
Update reference manual with details of Java configuration @Enable*
annotations. Examples of Java style @Configuration is provided
when appropriate alongside existing XML samples.
Several existing @Configuration samples have been changed to placing
the @Enable annotation below the @Configuration annotation.
This has been done to provide consistency with existing Javadoc.
Issue: SPR-9920
When a controller method declares Callable or DeferredResult as its
return value, and returns null, async processing will not start and
the request will be considered "handled" by the controller method.
Issue: SPR-9951
Tiles 3 has modified packages and classes as well as additional
dependencies, notably "tiles-request-api", which is a request/response
abstraction independent of Servlet and JSP APIs.
In order to have both Tiles 2 and Tiles 3 integrations, the source for
the Tiles 3 integration is in a separate project spring-webmvc-tiles3.
The build process merges the compiled Tiles 3 integration classes into
the spring-webmvc module so in effect it contains both the Tiles 2 and
the Tiles 3 integrations.
This change originated as a pull request at spring-framework-issues:
https://github.com/SpringSource/spring-framework-issues/pull/30
And was additionally updated:
https://github.com/SpringSource/spring-framework-issues/commit/1f64be4aa59b4766f9cc5fc6ead621d29f92a0d6
Issue: SPR-8825
Update Javadoc to indicate that the getAsyncExecutor() method may be
optionally annotated with @Bean and in such circumstance the
executor.initialize() method need not be called.
Issue: SPR-9934
Modify ReflectivePropertyAccessor so that it no longer considers
bridge methods when finding getters or setters. This should help
to prevent subtle errors that can occur when particular JDK
implementations happen to return bridge methods before non-bridge
methods when calling Class.getMethods()
Issue: SPR-9994
This change ensures that the location attribute of a resource mapping
and the path attribute of an interceptor mapping support SpEL
expressions.
Issue: SPR-9291, SPR-9848
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
The change removes the use of concrete Matcher implementations and thus
the dependency on hamcrest-lib leaving hamcrest-core as the only
(optional) hamcrest dependency.
Issue: SPR-9961
This commit increases the sleep time in
ScheduledAndTransactionalAnnotationIntegrationTests with the hope of
improving the robustness of the test suite on the CI build server.
This commit refactors the logic in DateTimeFormatterFactory's
createDateTimeFormatter() method to ensure forward compatibility with
possible future changes to the ISO enum.
This commit also polishes the Javadoc for DateTimeFormatterFactoryBean.
Issue: SPR-9959
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
Prior to this change, zip archives were named
spring-${version}-${classifier}.zip
e.g.:
- spring-3.2.0.RC1-dist.zip
- spring-3.2.0.RC1-docs.zip
- spring-3.2.0.RC1-schema.zip
This commit updates the Gradle build script to ensure that the fully-
qualified 'spring-framework' name is used consistently, such that names
follow the pattern
spring-framework-${version}-${classifier}.zip
This includes the naming of the root-level directory within the -dist
zip.
Issue: SPR-9954
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
* SPR-7121:
Support for custom global Joda DateTimeFormatters
Move JRuby dependency below Joda
Support DateTimeFormat annotation without Joda
Corrected date pattern in JavaDocs
Polish whitespace and formatting
Added dateFormatter, timeFormatter and dateTimeFormatter properties
to JodaTimeFormatterRegistrar allowing for custom global formatting.
DateTimeFormatterFactory can be used when configuring with XML.
Issue: SPR-7121
JRuby includes a copy of joda classes with the same package names.
This commit changes the order of the loaded jars to load the original
joda classes first.
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
* SPR-9796:
Update cache to support concurrent reads
Cache and late resolve annotations for performance
Polish Property class
Develop ConcurrentReferenceHashMap
Develop a new ConcurrentMap implementation that support both weak and
soft entry references. Intended primarily to be used internally to
support fast concurrent caching.
Issue: SPR-9796
This is more specific exception raised instead of RestClientException
when the raw HTTP status code received from the server is not one of
the HttpStatus enum values.
Issue: SPR-9406
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
Prior to this change,
FrameworkServlet#configureAndRefreshWebApplicationContext called
#postProcessWebApplicationContext(wac) and #applyInitializers(wac)
prior to #refresh, but because servlet-based property source stubs were
not replaced until #refresh, any post-processing or initialization
routines could not benefit from accessing the Environment to retrieve
properties from the ServletContext or ServletConfig.
The workaround to this problem is detailed in SPR-9610 - the user simply
needed to call WebApplicationContextUtils#initServletPropertySources
manually within their ApplicationContextInitializer (or overridden
#postProcessWebApplicationContext method)
This commit ensures that
FrameworkServlet#configureAndRefreshWebApplicationContext calls
WebApplicationContextUtils#initServletPropertySources eagerly, prior to
invoking #postProcessWebApplicationContext and #applyInitializers.
Related Javadoc has also been updated throughout to clarify the behavior
of #initServletPropertySources, when it can be called and what the
effects are, etc.
Note also that a reproduction issue was added to demonstrate the problem
and verify its resolution [1].
[1]: https://github.com/SpringSource/spring-framework-issues/tree/master/SPR-9610
Issue: SPR-9610
1) removed the hamcrest-all dependency requirement and replaced it with
the more focused hamcrest-library dependency
2) added MatcherAssertionErrors as a replacement of
org.hamcrest.MatcherAssert, which in hamcrest 1.1 is only available
through the hamcrest-all dependency (and not in hamcrest-core nor in
the hamcrest embedded in JUnit 4.4 through 4.8)
3) changed the required hamcrest version from 1.1 to 1.3 and made sure
the spring-test-mvc project does not rely on newer hamcrest
functionality without checking if it is available first
Applications that already depend on older versions of hamcrest
(in particular 1.1) via hamcrest-library, hamcrest-all or as part of
junit 4.4 through 4.8 should not be disrupted if they add spring-test
but may wish to exclude the hamcrest-library transitive dependency
from spring-test in order to avoid extra jars in the classpath
Applications that depend on hamcrest 1.3 should not have to do anything
Issue: SPR-9940
This setting was causing failures in the CI build, and was not present
prior to the recent updates to gradle wrapper generation.
This commit also simplifies the gradle wrapper customizations by placing
the logic in a doLast block within the original 'wrapper' task, as
to creating a second wrapper task and extending from the first.
The original commit c9b7b1 ensured the ability to read parameterized
type @RequestBody arguments via GenericHttpMessageConverter (e.g.
application/json and List<String>). However, it also affected the
ability to read @RequestBody arguments that happen are parameterized
but aren't treated as such (e.g. application/x-www-form-urlencoded and
MultiValueMap<String, String>). This commit corrects the issue.
Issue: SPR-9570
For @RequestBody(required=false), it is not sufficient to check if the
InputStream is null. This change reads the first byte of the request
InputStream to determine if the request body is empty or not.
If the InputStream implementation supports mark(int) and reset(), then
we use those. Otherwise we use PushbackInputStream to read and unread
the first byte.
All of this is done only if the required flag of @RequestBody is set
to "false" (default is "true").
Issue: SPR-9942
This commit validates the claims made in SPR-9799.
- Spr9799XmlConfigTests demonstrates that a WAC is not always necessary
when integration testing with XML configuration that uses
<mvc:annotation-driven />.
- Spr9799AnnotationConfigTests demonstrates that a WAC is in fact
necessary when integration testing with a configuration class that
uses @EnableWebMvc.
Issue: SPR-9799
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
Improve the #toString method for AnnotationAttributes to print array
values as a comma-separated list. This change is primarily to provide
better variable inspection when debugging code within an IDE.
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
Remove canBypassConvert() methods from the ConversionService SPI
interface, restoring it to the previous Spring 3.1 incarnation.
Bypassing conversion is now only supported when using a
GenericConversionService.
Issue: SPR-9566
Bypass ObjectToObject conversion when source and object types are
identical and protect against a null source object.
Prior to this commit the TypeDescriptor was used to determine if
conversion was necessary. This caused issues when comparing a
descriptor with annotations to one without. The updated code
now compares using TypeDescriptor.getType().
The ObjectToObject converter will now no longer attempt to convert
null source objects.
Issue: SPR-9933
TypeDescriptor.valueOf now uses GenericCollectionTypeResolver to resolve
Collection and Map element types whereas previously this information was
simply not supported, i.e. null.
Issue: SPR-9257
Expand the kinds of tokens considered when parsing qualified type names.
This allows previously reserved words (for example 'mod') to be used as
part of a package name.
Issue: SPR-9862
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
# By Phillip Webb (6) and Chris Beams (1)
* SPR-9692:
Review and polish pull request #132
Support conversion from Enum Interface
Test SpEL unconditional argument conversion
Bypass conversion when possible
Extend conditional conversion support
Refactor GenericConversionService
Additional GenericConversionService Tests
Prior to this commit conversion between like types would often result in
a copy of the object. This can be problematic in the case of large byte
arrays and objects that do not have a default constructor.
The ConversionService SPI now includes canBypassConvert methods that can
be used to deduce when conversion is not needed. Several existing
converters have been updated to ensure they only apply when source and
target types differ.
This change introduces new methods to the ConversionService that will
break existing implementations. However, it anticipated that most users
are consuming the ConversionService interface rather then extending it.
Issue: SPR-9566
Introduce new ConditionalConversion interface that can be applied to
Converter, ConverterFactory or GenericConverter interfaces to make
them conditional. Prior to this commit the only
ConditionalGenericConverter could be conditional.
Issue: SPR-9928
Refactor internal workings of GenericConversionService in order to
better support future enhancements. This commit should not affect
existing behavior.
Issue: SPR-9927
The servlet spec recommends removing path parameters from the
contextPath, servletPath, and pathInfo but not from the requestURI.
This poses a challenge for the UrlPathHelper, which determines the
lookup path by comparing the above.
This change introduces a method that matches the requestURI to the
contextPath and servletPath ignoring path parameters (i.e. matrix
variables) for comparison purposes while also preserving them in the
resulting lookup path.
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
Code introduced in conjunction with SPR-5243 introduced package cycles
between the ~.test.context and ~.test.context.web packages. This was
caused by the fact that ContextLoaderUtils worked directly with the
@WebAppConfiguration and WebMergedContextConfiguration types.
To address this, the following methods have been introduced in
ContextLoaderUtils. These methods use reflection to circumvent hard
dependencies on the @WebAppConfiguration and
WebMergedContextConfiguration types.
- loadWebAppConfigurationClass()
- buildWebMergedContextConfiguration()
Issue: SPR-9924
Prior to this commit, the following two methods in ContextLoaderUtils
contained almost identical loops for traversing the test class
hierarchy:
- resolveContextLoaderClass(Class<?>, String)
- resolveContextConfigurationAttributes(Class<?>)
With this commit, resolveContextLoaderClass() no longer traverses the
class hierarchy. Instead, it now works directly with the resolved list
of ContextConfigurationAttributes, thereby removing code duplication.
Issue: SPR-9918
Code introduced in conjunction with SPR-5243 introduced package cycles
between the ~.test.context.web and ~.test.context.support packages. This
was caused by the fact that ServletTestExecutionListener extended
AbstractTestExecutionListener.
To address this, ServletTestExecutionListener now implements
TestExecutionListener directly.
Issue: SPR-9924
Prior to this commit the MockHttpServletRequest constructor chain set
the preferred local to Locale.ENGLISH. Furthermore, it was possible to
add additional preferred locales "in front" of ENGLISH; however, it was
not possible to delete ENGLISH from the list of preferred locales.
This commit documents the fact that ENGLISH is the default preferred
locale and makes it possible to set the list of preferred locales via a
new setPreferredLocales(List<Locale> locales) method.
Issue: SPR-9724
The MVC namespace and the MVC Java config now allow configuring
CallableProcessingInterceptor and DeferredResultProcessingInterceptor
instances.
Issue: SPR-9914
New afterTimeout and afterCompletion callbacks
afterTimeout can provide a concurrent result to be used instead of the
one that could not be set or returned on time
Interceptor exceptions cause async processing to resume treating the
exception as the concurrent result
Adapter classes for convenient implementation of the interfaces
Issue: SPR-9914
Prior to this commit, the PropertyResolver API (and therefore the
Environment API) allowed callers a choice between
#resolvePlaceholders and #resolveRequiredPlaceholders for low-level
${placeholder} resolution. However, when calling the higher level
#getProperty variants, users had no control over whether property
values returned with unresolvable ${placeholders} would result in an
exception or simply be passed through.
This commit introduces a #setIgnoreUnresolvableNestedPlaceholders
property via ConfigurablePropertyResolver, defaulting to false, the
value of which is respected by AbstractPropertyResolver#getProperty
method implementations. See the new test in
PropertySourcesPropertyResolverTests for usage examples.
Issue: SPR-9569, SPR-9473
- Upgrade to 0.1.6 snapshot of docbook plugin
- Fully qualify PDF artifact name as 'spring-framework-reference.pdf'
instead of former 'spring-reference.pdf'
Issue: SPR-9598
Moving @EnableMBeanExport and its MBeanExportConfiguration
@Configuration class into context.annotation caused a side effect with
ComponentScanningWithLTWTests, which component scans context.annotation
in order to test LTW behavior. Picking up MBeanExportConfiguration
without proper MBean configuration resulted in a NullPointerException
during test execution.
This commit simply filters out all @Configuration classes from the LTW
test's component-scanning directive.
Issue: SPR-8943
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
Commit 5327a7a37d moved
@EnableSpringConfigured from beans.factory.aspectj =>
context.annotation within the spring-aspects module. This resolved a
package cycle but had the side-effect of causing a "split package" [1]
problem between spring-context and spring-aspects in OSGi-based
classloader environments because the context.annotation package now
exists in both modules.
The simplest and best solution from an OSGi perspective is to relocate
@EnableSpringConfigured and its supporting SpringConfiguredConfiguration
class into a new package. This commit moves both these types into
context.annotation.aspectj, following convention with other such
"aspectj"-qualified packages in the spring-aspects module.
As with the previous move, it is presumed this change will be low-impact
as the "spring-configured" approach to domain object injection is a
niche feature to begin with, and @EnableSpringConfigured has existed in
its current location only since 3.1.2 and this change is being made in
time for 3.1.3.
[1]: http://wiki.osgi.org/wiki/Split_Packages
Issue: SPR-9811, SPR-9441
Prior to this change, LocalJaxWsServiceFactory allowed specifying a WSDL
document URL. Now users may also specify a WSDL document represented as
a Spring Resource object for convenience.
Issue: SPR-9909
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
This change ensures that SpEL expressions involving floats are
supported natively as opposed to the previous behavior which required
conversion to double, leading to potential downstream conversion
ambiguities.
Issue: SPR-9486
With this commit the Spring Expression Language now supports
increment (++) and decrement (--) operators. These can be
used as either prefix or postfix operators. For example:
'somearray[index++]' and 'somearray[--index]' are valid.
In order to support this there are serious changes to the
evaluation process for expressions. The concept of a
value reference for an expression component has been introduced.
Value references can be passed around and at any time the actual
value can be retrieved (via a get) or set (where applicable). This
was needed to avoid double evaluation of expression components.
For example, in evaluating the expression 'somearray[index++]--'
without a value reference SpEL would need to evaluate the
'somearray[index++]' component twice, once to get the value and
then again to determine where to put the new value. If that
component is evaluated twice, index would be double incremented.
A value reference for 'somearray[index++]' avoids this problem.
Many new tests have been introduced into the EvaluationTests
to ensure not only that ++ and -- work but also that the
introduction of value references across the all of SpEL has
not caused regressions.
Issue: SPR-9751
When obtaining an async result, tests will now await concurrent
processing to complete for the exact amount of time equal to the
actual async timeout value.
Issue: SPR-9875
Before this change View implementations set the response content type
to the fixed value they were configured with.
This change makes it possible to configure a View implementation with
a more general media type, e.g. "application/*+xml", and then set the
response type to the more specific requested media type, e.g.
"application/vnd.example-v1+xml".
Issue: SPR-9807.
Some servlet containers (iPlanet) parse the Accept header and return
multiple values from request.getHeader("Accept"). The HttpHeaders
getAccept method has been updated to accommodate that hopefully
without causing any other issues.
The extra functionality is in effect only if we find only one
MediaType and there is more than one value for the 'Accept' header.
Issue: SPR-9655
Previously UriComponentsBuilder used a regular expression for parsing
query name-value pairs where both name and value were expected to not
contain neither '&', not '='. The idea is that the presence of reserved
characters makes it impossible to guess correctly how to parse the
query string (e.g. a=b&c).
This change relaxes the constraint on query param values, allowing them
to contain '='. In effect '&' is the ultimate separator of name-value
pairs, and any '=' in values is ignored. For example "q=1USD=?EUR" is
interpreted as "q equals '1USD=?EUR'".
Issue: SPR-9832
Prior to this commit, utility methods in JdbcTestUtils interpreted SQL
comments as separate statements, resulting in an exception when such a
script is executed.
This commit addresses this issue by introducing a
readScript(lineNumberReader, String) method that accepts a comment
prefix. Comment lines are therefore no longer returned in the parsed
script. Furthermore, the existing readScript(lineNumberReader) method
now delegates to this new readScript() method, supplying "--" as the
default comment prefix.
Issue: SPR-9593
SpringRunnerContextCacheTests suffers from JDK7-related non-determinism
in values returned from Class#getDeclaredMethods(), which in turn
affects JUnit and its execution of @Test methods.
This commit addresses this issue by introducing an
OrderedMethodsSpringJUnit4ClassRunner that sorts the test methods
alphabetically, which is actually required for
SpringRunnerContextCacheTests to work properly.
Issue: SPR-9789
This commit introduces RequestAndSessionScopedBeansWacTests which
verifies support for request and session scoped beans in the Spring
TestContext Framework (TCF).
This support was actually introduced as an intentional side effect of
the work performed for SPR-5243 through the addition of the new
WebTestExecutionListener.
Issue: SPR-4588
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
* SPR-9284:
Allow MapToMap conversion to work when the target map does not have a default constructor (as long as a new map copy is not required).
Polish trailing whitespace
Update the ReflectiveMethodResolver and ReflectivePropertyAccessor
to allow methods and properties of java.lang.Class to be resolved
when the target object is a class.
Issue: SPR-9017
Refactor ConfigurationClassEnhancer to allow cglib caching of
generated classes. Prior to this commit each enhanced @Configuration
class would consume permgen space when created.
The CallbackFilter and Callback Types are now defined as static final
members so that they can be shared by all enhancers. Only the
callbackInstances remain specific to a @Configuration class and
these are not used by cglib as part of the cache key.
Issue: SPR-9851
This change ensures that when the Accept and the Producible media types
are equally specific, we use the one from the Accept header, which may
for example carry a different charset.
Remove use of UriTemplate in MockMvcRequestBuilders.
Rely on UriComponentsBuilder instead.
Decode query params before setting them on MockHttpServletRequest.
Add more options to model result matching for the count of errors.
Ignore white spaces and comments when comparing XML.
Aside from minor polishing, this change sets the "systemProperties" and "systemEnvironment" beans at each factory level as well.
Issue: SPR-9756
Issue: SPR-9764
Add "MockRest-" prefix to RequestMatchers and ResponseCreators to
make it easy to find classes with static imports with
Ctrl+Shift+T "MockRest" - similar to the "MockMvc"
prefix on the server-side.
This change fixes further cases under JDK 6 in which setting a bridged
(e.g. String-returning) read method can conflict with an existing
corresponding bridge write method that accepts an Object parameter.
This appears to be a implementation difference between JDKs 6 and 7,
where the JDK 6 Introspector adds bridge methods and JDK 7 does not.
The solution here is to consistently null-out any existing write method
before setting the read method. We were doing this elsewhere in
ExtendedBeanInfo already, but these two changes make the approach
consistent throuhout.
Issue: SPR-8806
Prior to this commit, the Spring TestContext Framework only supported
loading an ApplicationContext in integration tests from either XML or
Java Properties files (since Spring 2.5), and Spring 3.1 introduced
support for loading an ApplicationContext in integration tests from
annotated classes (e.g., @Configuration classes). All of the
ContextLoader implementations used to provide this support load a
GenericApplicationContext. However, a GenericApplicationContext is not
suitable for testing a web application since a web application relies on
an implementation of WebApplicationContext (WAC).
This commit makes it possible to integration test Spring-powered web
applications by adding the following functionality to the Spring
TestContext Framework.
- Introduced AbstractGenericWebContextLoader and two concrete
subclasses:
- XmlWebContextLoader
- AnnotationConfigWebContextLoader
- Pulled up prepareContext(context, mergedConfig) from
AbstractGenericContextLoader into AbstractContextLoader to allow it
to be shared across web and non-web context loaders.
- Introduced AnnotationConfigContextLoaderUtils and refactored
AnnotationConfigContextLoader accordingly. These utils are also used
by AnnotationConfigWebContextLoader.
- Introduced a new @WebAppConfiguration annotation to denote that the
ApplicationContext loaded for a test should be a WAC and to configure
the base resource path for the root directory of a web application.
- Introduced WebMergedContextConfiguration which extends
MergedContextConfiguration with support for a baseResourcePath for
the root directory of a web application.
- ContextLoaderUtils.buildMergedContextConfiguration() now builds a
WebMergedContextConfiguration instead of a standard
MergedContextConfiguration if @WebAppConfiguration is present on the
test class.
- Introduced a configureWebResources() method in
AbstractGenericWebContextLoader that is responsible for creating a
MockServletContext with a proper ResourceLoader for the
resourceBasePath configured in the WebMergedContextConfiguration. The
resulting mock ServletContext is set in the WAC, and the WAC is
stored as the Root WAC in the ServletContext.
- Introduced a WebTestExecutionListener that sets up default thread
local state via RequestContextHolder before each test method by using
the MockServletContext already present in the WAC and by creating a
MockHttpServletRequest, MockHttpServletResponse, and
ServletWebRequest that is set in the RequestContextHolder. WTEL also
ensures that the MockHttpServletResponse and ServletWebRequest can be
injected into the test instance (e.g., via @Autowired) and cleans up
thread locals after each test method.
- WebTestExecutionListener is configured as a default
TestExecutionListener before DependencyInjectionTestExecutionListener
- Extracted AbstractDelegatingSmartContextLoader from
DelegatingSmartContextLoader and introduced a new
WebDelegatingSmartContextLoader.
- ContextLoaderUtils now selects the default delegating ContextLoader
class name based on the presence of @WebAppConfiguration on the test
class.
- Tests in the spring-test-mvc module no longer use a custom
ContextLoader to load a WebApplicationContext. Instead, they now
rely on new core functionality provided in this commit.
Issue: SPR-5243
Caching of resovled exceptions introduced in SPR-7703 also introduced a
side effect whereby if exactly one exception was previously cached, any
other exception would appear as a match to the previously matched
@ExceptionHandler method.
This change ensures use of a fresh map when determining matching
@ExceptionHandler methods while also updating the cache.
Issue: SPR-9209
An additional update (after the last commit) of the "includes" and
"isCompatibleWith" methods of MediaType to accomodate wildcards
in media types with a suffix.
Issue: SPR-9841
The "includes" and "isCompatibleWith" methods of MediaType take into
account media types with suffices (e.g. application/soap+xml) including
wildcards with suffices (e.g. application/*+xml). However before this
change, the isWildcardSubtype() method returned true only for subtype
"*". Now a media type such as application/*+xml is also recognized as
having a wildcard subtype.
Issue: SPR-9841
Previously the project that was getting merged from would try to
execute the artifactoryPublish on the build box. This caused issues
since the mavenDescriptor did not exist.
The merge-dist.gradle now disables the artifactoryPublish task if it
exists (it will only exist on the build box).
Issue: SPR-9859, SPR-7951
This commit adds the spring-test-mvc project [1] to the Spring
Framework as part of the spring-test module.
The sources are added as a root-level project called "spring-test-mvc"
instead of under "spring-test" because the new sources need to be
compiled with Servlet 3 while the current "spring-test" sources require
Servlet 2.5 and the Eclipse IDE does not support having different
classpaths for the same project.
The Gradle build produces a single spring-test jar that contains
sources from both "spring-test" and "spring-test-mvc". This merge is
made possible through merge-dist.gradle as follows:
- jar tasks of the "from" project execute tasks of the "to" project
- "to" project is added to the classpath of the "from" project
- "to" project pom is updated with entries from the "from" project
For further details see documentation in merge-dist.gradle.
Special thanks to everyone who contributed to the initial development
of the Spring MVC Test framework:
Arjen Poutsma <poutsma@mac.com>
Craig Walls <cwalls@vmware.com>
Frans Flippo <fransflippo@utopia.orange11.nl>
Harry Lascelles <harry@firstbanco.com>
Irfan <mail.urfi@gmail.com>
Jörg Rathlev <joerg.rathlev@s24.com>
Keesun Baik <whiteship2000@gmail.com>
Keesun Baik <whiteship@epril.com>
Matthew Reid <matthew.reid@nakedwines.com>
Nils-Helge Garli Hegvik <Nils-Helge.Hegvik@telenor.com>
Rob Winch <rwinch@vmware.com>
Scott Frederick <sfrederick@vmware.com>
Sven Filatov <sven.filatov@gmail.com>
Thomas Bruyelle <thomas.bruyelle@gmail.com>
youngm <youngm@gmail.com>
[1]: https://github.com/SpringSource/spring-test-mvc
Issue: SPR-9859, SPR-7951
This should be significantly faster than our standard algorithm, for a very common case. Motivated by SPR-9802, even if the fix there uses a different approach, with transaction name determination not calling getMostSpecificMethod at all anymore.
Issue: SPR-9802
As of Spring 3.0.4, we were trying to expose the target method signature as transaction name. Unfortunately, the algorithm called the ClassUtils.getMostSpecificMethod helper method which performs a quite expensive reflective search. As of this commit, we're simply concatenating the target class name with the method name, accepting the use of the concrete target class (which is arguably more meaningful for monitoring anyway) even when the method implementation actually sits on a base class.
Issue: SPR-9802
These features require Java 6 or higher due to their dependency on the ResourceBundle.Control class. To some degree, ResourceBundleMessageSource catches up with ReloadableResourceBundleMessageSource now. However, as noted in the javadoc, there are still severe limitations in the standard ResourceBundle class that justify an ongoing investment in our own ReloadableResourceBundleMessageSource (based on the Spring resource abstraction, with manual parsing of properties files).
Issue: SPR-7392
Before this change the PathExtensionContentNegotiationStrategy accessed
the ServletContext via request.getServletContext, which is Servlet 3
specific. To work around it, there is now a Servlet-specific sub-class
that accepts a ServletContext as a constructor argument.
The ContentNegotiationManagerFactoryBean is now ServletContextAware and
if it has a ServletContext it creates the Servlet-specific sub-class
of PathExtensionContentNegotiationStrategy.
The ContentNegotiationManagerFactoryBean is now also used in several
places internally -- MVC namespace, MVC Java config, and the
ContentNegotiatingViewResolver -- to reduce duplication.
Issue: SPR-9826
Before this commit, UriComponentsBuilder did not handle opaque URIs at
all. After this commit it does.
Support is introduced by making UriComponents an abstract base class,
and having two concrete subclasses: HierarchicalUriComponents and
OpaqueUriComponents. The former is more or less the same as the old
UriComponents class.
Issue: SPR-9798
This new converter uses StringHttpMessageConverter internally combined
with a ConversionService for converting String content to and from the
target object type.
Issue: SPR-9738
Autowired methods might have been skipped on subsequent creation of further bean instances due to the 'skip' flag set to false outside of the synchronized block, with another thread entering the block and setting the flag to true in the meantime.
Issue: SPR-9806
LiveBeansView includes MBean exposure as well as Servlet exposure, with JSON as the initial output format. In order to identify an MBean per application, a new "getApplicationName()" method got introduced on the ApplicationContext interface, returning the Servlet container context path in case of a web application and defaulting to the empty String. MBean exposure can be driven by the "spring.liveBeansView.mbeanDomain" property, e.g. specifying "liveBeansView" as its value, leading to "liveBeansView:application=" or "liveBeansView:application=/myapp" style names for the per-application MBean.
Issue: SPR-9662
The RequestMethodsRequestCondition is now protected against HTTP
request method values not present in the RequestMethod enumeration
(e.g. PROPFIND).
Issue: SPR-9815
This change introduces two new interceptors with callback methods
for concurrent request handling. These interfaces are
CallableProcessingInterceptor and DeferredResultProcessingInterceptor.
Unlike a HandlerInterceptor, and its AsyncHandlerInterceptor sub-type,
which intercepts the invocation of a handler in he main request
processing thread, the two new interfaces are aimed at intercepting the
asynchronous execution of a Callable or a DeferredResult.
This allows for the registration of thread initialization logic in the
case of Callable executed with an AsyncTaskExecutor, or for centralized
tracking of the completion and/or expiration of a DeferredResult.
Prior to this commit, JibxMarshaller used a SAX ContentHandler to
marshal to StAX XMLEventWriters, which inadvertently resulted in the
deletion of XML comments.
After this commit, JibxMarshaller adapts the XMLEventWriter into an
XMLStreamWriter and comments are preserved.
Issue: SPR-9768
Prior to this change, @ComponentScan required the declaration of
exactly one of the #value, #basePackage or #basePackageClasses
attributes in order to determine which package(s) to scan.
This commit introduces support for base package inference, relaxing the
above requirement and falling back to scanning the package in which the
@ComponentScan-annotated class is declared.
Issue: SPR-9586
Float parameter handling appears to be marginally more expensive under
JDK7, with the testGetFloatParameterWithDefaultValueHandlingIsFastEnough
test clocking in anywhere from 250 to 315 ms. This violates the current
test threshold of 250 ms, so this commit ups the timeout value to 350 ms
with the assumption that this is indeed a marginal and therefore overall
negligible performance degradation.
String#substring has become significantly slower as of JDK 1.7.0_06 [1],
such that there are performance degradations by a factor of 100-1000 in
ResourceDatabasePopulator, especially for large SQL files.
This commit works around this problem by minimizing the substring scope
to the least amount possible to prevent unnecessary internal copying of
strings (which seems to cause the issue).
[1]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-May/010257.html
Issue: SPR-9781
Class#getDeclaredMembers returns arbitrary results under JDK7. This
results in non-deterministic execution of JUnit test methods, often
revealing unintended dependencies between methods that rely on a
specific order to succeed.
JUnit 4.11 contains support for predictable test ordering [1], but at
the time of this commit, JUnit 4.11 has not yet been released.
Therefore we are testing against a snapshot version [2], which has been
uploaded to repo.springsource.org [3] for easy access. Note that this
artifact may be removed when JUnit 4.11 goes GA.
- Care has been taken to ensure that spring-test's compile-time
dependency on JUnit remains at 4.10. This means that the spring-test
pom.xml will continue to have an optional <dependency> on JUnit
4.10, instead of the 4.11 snapshot.
- For reasons not fully understood, the upgrade to the 4.11 snapshot
of junit-dep caused NoSuchMethodErrors around certain Hamcrest
types, particularly CoreMatchers and Matchers. import statements
have been updated accordingly throughout affected test cases.
- Runtime errors also occurred around uses of JUnit @Rule and
ExpectedException. These have been reverted to use simpler
mechanisms like @Test(expected) in the meantime.
- Some test methods with order-based dependencies on one another have
been renamed in order to fall in line with JUnit 4.11's new method
ordering (as opposed to actually fixing the inter-test
dependencies). In other areas, the fix was as simple as adding a
tearDown method and cleaning up state.
- For no apparent reason, the timeout in AspectJAutoProxyCreatorTests'
testAspectsAndAdvisorNotAppliedToPrototypeIsFastEnough method begins
to be exceeded. Prior to this commit the timeout value was 3000 ms;
on the CI server under Linux/JDK6 and JDK7, the test begins taking
anywhere from 3500-5500 ms with this commit. It is presumed that
this is an incidental artifact of the upgrade to JUnit 4.11. In any
case, there are no changes to src/main in this commit, so this
should not actually represent a performance risk for Spring
Framework users. The timeout has been increased to 6000 ms to
accommodate this situation.
[1]: https://github.com/KentBeck/junit/pull/293
[2]: https://github.com/downloads/KentBeck/junit/junit-dep-4.11-SNAPSHOT-20120805-1225.jar
[3]: https://repo.springsource.org/simple/ext-release-local/junit/junit-dep/4.11.20120805.1225
Issue: SPR-9783
- Allow reset of GlobalAdvisorAdapterRegistry
Provide a reset() method allowing the GlobalAdvisorAdapterRegistry
instance to be replaced with a fresh instance. This method has
primarily been added to allow unit tests to leave the registry
in a known state.
- Protect against the fact that calls to configuration class methods
my occur in a random order.
Issue: SPR-9779
- 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
DefaultHandlerExceptionResolver and ResponseEntityExceptionHandler now
both set the "javax.servlet.error.exception" request attribute to the
raised exception, allowing custom error pages configured via web.xml.
Issue: SPR-9653
While HandlerMethod instances are cached for lookup purposes, a new
ServletInvocableHandlerMethod instance has to be created prior to each
invocation since handlers may have non-singleton scope semantics.
This change reduces the overhead of creating per request instances
by using a logger with a fixed name rather than relying on getClass()
and also by copying introspected method parameters from the cached
HandlerMethod instance.
Issue: SPR-9747, SPR-9748
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
This change fixes a cyclical package dependency.
The change also improves the implementation of
WebAsyncManager.hasConcurrentResult() following the resolution of
Apache issue id=53632 and the release of Apache Tomcat 7.0.30 that
contains the fix.
Update the ReflectiveAspectJAdvisorFactory class to sort candidate
AOP methods based on their annotation first and method name second.
Prior to this the order of aspects created from annotated methods
could differ depending on the underling JVM, as first noticed under
JDK7 in SPR-9729.
- ConvertingComparator and InstanceComparator have been introduced in
support of this change, per SPR-9730.
- A shared static INSTANCE field has been added to ComparableComparator
to avoid unnecessary instantiation costs within ConvertingComparator
as well as to prevent generics warnings during certain caller
scenarios.
Issue: SPR-9729, SPR-9730
Before this commit, the Jaxb2Marshaller required all supported classes
to be annotated with @XmlRootElement. This commit adds a property
'checkForXmlRootElement' (default is true) which allows for un-annotated
classes.
This is especially useful for JAXB2 implementations that can use
external binding files, such as EclipseLink MOXy.
Issue: SPR-9757
This commit avoids eager creation of Environment instances, favoring
delegation of already existing Environment objects where possible. For
example, FrameworkServlet creates an ApplicationContext; both require
a StandardServletEnvironment instance, and prior to this change, two
instances were created where one would suffice - indeed these two
instances may reasonably be expected to be the same. Now, the
FrameworkServlet defers creation of its Environment, allowing users to
supply a custom instance via its #setEnvironment method (e.g. within a
WebApplicationInitializer); the FrameworkServlet then takes care to
delegate that instance to the ApplicationContext created
in #createWebApplicationContext.
This behavior produces more consistent behavior with regard to
delegation of the environment, saves unnecessary cycles by avoiding
needless instantiation and calls to methods like
StandardServletEnvironment#initPropertySources and leads to better
logging output, as the user sees only one Environment created and
initialized when working with the FrameworkServlet/DispatcherServlet.
This commit also mirrors these changes across the corresponding
Portlet* classes.
Issue: SPR-9763
This change fixes a minor bug with the implementation of
ConfigurableEnvironment#merge, introduced in SPR-9444. During a merge
of two environments A and B, where A has default profiles [prod] and B
has default profiles [default] (the so-called 'reserved default
profile'), B would complete the merge process having a collection of
profiles reading [default, prod], which is incorrect.
This commit explicitly ensure's that B's reserved default profile is
removed if A has a set of default profiles greater than zero. If A
consists only of [default], B will inherit it during the merge
correctly; if A consists of [p1, p2], B will result in [p1, p2] as
well; if B consists of [p1] and A of [p2, p3], B will result in
[p1, p2, p3] post-merge.
Issue: SPR-9761, SPR-9444
Prior to this change, AbstractApplicationContext#prepareBeanFactory
registered a bean named 'environment' once and only once within a given
ApplicationContext hierarchy. This worked fine with the expectation
that the Environment object is always delegated downward to children of
that hierarchy. However, with SPR-9444 and the introduction of
ConfigurableEnvironment#merge, this expectation was violated; each
member of an application context hierarchy now maintains its own
distinct Environment instance, which means that by extension that each
application context's underlying BeanFactory should have its own
'environment' bean pointing to that context's environment instance.
This problem could manifest in getting the wrong environment instance
when calling #getBean(Environment) or when @Autowiring an Environment
instance, for example into a @Configuration class. As reported in
SPR-9756, this could result in false negative property lookups or
incorrect results when checking whether a profile is active.
This commit ensures that every bean factory in an application
hierarchy has an 'environment' bean referring to the object returned
from the enclosing ApplicationContext#getEnvironment method.
Issue: SPR-9756, SPR-9444
The AbstractDispatcherServletInitializer now provides support for
the registration of filters to be mapped to the DispatcherServlet.
It also sets the asyncSupported flag by default on the
DispatcherServlet and all registered filters.
Issue: SPR-9696
A new @MatrixVariable annotation allows injecting matrix variables
into @RequestMapping methods. The matrix variables may appear in any
path segment and should be wrapped in a URI template for request
mapping purposes to ensure request matching is not affected by the
order or the presence/absence of such variables. The @MatrixVariable
annotation has an optional "pathVar" attribute that can be used to
refer to the URI template where a matrix variable is located.
Previously, ";" (semicolon) delimited content was removed from the
path used for request mapping purposes. To preserve backwards
compatibility that continues to be the case (except for the MVC
namespace and Java config) and may be changed by setting the
"removeSemicolonContent" property of RequestMappingHandlerMapping to
"false". Applications using the MVC namespace and Java config do not
need to do anything further to extract and use matrix variables.
Issue: SPR-5499, SPR-7818
Rename ExceptionHandlerSupport to ResponseEntityExceptionHandler and
emphasize the contrast to DefaultHandlerExceptionResovler -- i.e.
one returns a ResponseEntity and relies on message converters while
the other returns a ModelAndView and relies on view resolution.
Issue: SPR-9290
Before this commit, the CachedIntrospectionResults was hard-coded to
create ExtendedBeanInfos for bean classes. The ExtendedBeanInfo support
the JavaBeans property contract only.
This commit introduces the BeanInfoFactory, a strategy for creating
BeanInfos. Through this strategy, it is possible to support
beans that do not necessarily implement the JavaBeans contract (i.e.
have a different getter or setter style).
BeanInfoFactories are are instantiated by the
CachedIntrospectionResults, which looks for
'META-INF/spring.beanInfoFactories' files on the class path. These files
contain one or more BeanInfoFactory class names. When a BeanInfo is to
be created, the CachedIntrospectionResults will iterate through the
factories, asking it to create a BeanInfo for the given bean class. If
none of the factories support it, an ExtendedBeanInfo is created as a
default.
This commit also contains a change to Property, allowing BeanWrapperImpl
to specify the property name at construction time (as opposed to using
Property#resolveName(), which supports the JavaBeans contract only).
Issue: SPR-9677
This change makes it possible to declare an @RequestBody argument with
a generic type (e.g. List<Foo>). If a GenericHttpMessageConverter
implementation supports the method argument, then the request will be
converted to the apropiate target type.
The new GenericHttpMessageConverter is implemented by the
MappingJacksonHttpMessageConverter and also by a new
Jaxb2CollectionHttpMessageConverter that can read read a generic
Collection where the generic type is a JAXB type annotated with
@XmlRootElement or @XmlType.
Issue: SPR-9570
This change makes it possible to use the RestTemplate to read an HTTP
response into a target generic type object. The RestTemplate has three
new exchange(...) methods that accept ParameterizedTypeReference -- a
new class that enables capturing and passing generic type info.
See the Javadoc of the three new methods in RestOperations for a
short example.
To support this feature, the HttpMessageConverter is now extended by
GenericHttpMessageConverter, which adds a method for reading an
HttpInputMessage to a specific generic type. The new interface
is implemented by the MappingJacksonHttpMessageConverter and also by a
new Jaxb2CollectionHttpMessageConverter that can read read a generic
Collection where the generic type is a JAXB type annotated with
@XmlRootElement or @XmlType.
Issue: SPR-7023
The target parameters for a FlashMap must be decoded to be able to
match them to the parameters of incoming requests given that the
HttpServletRequest returns decoded request parameters.
SPR-9657
An @RequestBody or an @RequestPart argument can now be followed by an
Errors/BindingResult argument making it possible to handle validation
errors (as a result of an @Valid annotation) locally within the
@RequestMapping method.
Issue: SPR-7114
The new class is functionally equivalent to the
DefaultHandlerExceptionResolver (i.e. it translates Spring MVC
exceptions to various status codes) but uses an @ExceptionHandler
returning a ResponseEntity<Object>, which means it can be customized to
write error content to the body of the response.
Issue: SPR-9290
Starting with Spring 3.1 applications can specify
contextInitializerClasses via context-param and init-param in web.xml;
however, there is currently no way to have such initializers invoked in
integration testing scenarios without writing a custom
SmartContextLoader. For comprehensive integration testing it should
therefore be possible to re-use ApplicationContextInitializers in the
Spring TestContext Framework as well.
This commit makes this possible at the @ContextConfiguration level by
allowing an array of ACI types to be specified, and the out-of-the-box
SmartContextLoader implementations invoke the declared initializers at
the appropriate time.
- Added initializers and inheritInitializers attributes to
@ContextConfiguration.
- Introduced support for ApplicationContextInitializers in
ContextConfigurationAttributes, MergedContextConfiguration, and
ContextLoaderUtils.
- MergedContextConfiguration stores context initializer classes as a
Set and incorporates them into the implementations of hashCode() and
equals() for proper context caching.
- ApplicationContextInitializers are invoked in the new
prepareContext(GenericApplicationContext, MergedContextConfiguration)
method in AbstractGenericContextLoader, and ordering declared via the
Ordered interface and @Order annotation is honored.
- Updated DelegatingSmartContextLoader to support initializers.
Specifically, a test class may optionally declare neither XML
configuration files nor annotated classes and instead declare only
application context initializers. In such cases, an attempt will
still be made to detect defaults, but their absence will not result
an an exception.
- Documented support for application context initializers in Javadoc
and in the testing chapter of the reference manual.
Issue: SPR-9011
The MVC Java config method to implement is
WebMvcConfigurer.configureAsyncSupport(AsyncSupportConfigurer)
The MVC namespace element is:
<mvc:annotation-driven>
<mvc:async-support default-timeout="2500" task-executor="myExecutor" />
</mvc:annotation-driven>
Issue: SPR-9694
Methods returning DeferredResult can now specify a timeout value
through constructor arg while methods returning a Callable can wrap it
in an AsyncTask that also accepts a timeout and a specific task
executor.
Issue: SPR-9399
DeferredResult now has a setErrorResult method that can be set to an
Exception or an error object, error view, etc.
The new isSetOrExpired() method can be used to check pro-actively if
the DeferredResult is still usable or not.
The setDeferredResultHandler method is now public so tests may use it.
Issue: SPR-9690, SPR-9689
The invalidate() method in MockHttpSession is currently implemented
incorrectly. According to the Servlet specification, the method should
throw an IllegalStateException if it is invoked on an already
invalidated session. However, invoking invalidate() on the same
MockHttpSession instance multiple times does not throw an exception.
This commits addresses this issue by checking the invalid field and
throwing an IllegalStateException if it has already been set to true.
Issue: SPR-9686
Classes with this annotation can contain @ExceptionHandler,
@InitBinder, and @ModelAttribute methods that apply to all controllers.
The new annotation is also a component annotation allowing
implementations to be discovered through component scanning.
Issue: SPR-9112
spring-core, spring-aop and spring-context each have compile-time
dependencies on classes in the aspectjweaver jar. Prior to this commit,
only spring-core declared an optional dependency on it; now all three
do.
Issue: SPR-9683
Historically spring-orm has had an optional dependency on spring-web,
primarily in support of OpenSessionInView functionality. This optional
dependency was inadvertently made required when porting the build to
Gradle. This commit simply reintroduces the optional setting.
Issue: SPR-9632
XStreamMarshaller now supports writing to OutputStreams and reading from
InputStreams directly, as opposed to wrapping streams in a
OutputStreamWriter or InputStreamReader.
Issue: SPR-9663
Prior to this change, the repackaged spring-asm and spring-cglib jars
were being included wholesale in the spring-core jar, whereas the
intention was to include the unzipped classfiles.
This change ensures that spring-asm and spring-cglib jars are unzipped
on the fly when creating the spring-core jar.
Issue: SPR-9669
ReflectionTestUtils.setField() implicitly calls toString() on the target
object when arguments for a call to Assert.notNull() are built. This can
have undesirable side effects, for example if the toString() invocation
results in a thrown exception or access to an external system (e.g., a
database).
This commit addresses this issue by inlining the Assert.notNull() code,
thereby avoiding accidental invocation of toString() on a non-null
target.
Issue: SPR-9571
The default set of TestExecutionListeners is sufficient in most
integration testing scenarios; however, the TestContextManager
nonetheless logs an INFO message if the @TestExecutionListeners
annotation is not present on an integration test class.
In order to avoid flooding the logs with messages about the absence of
@TestExecutionListeners, this commit reduces the log level for such
messages from INFO to DEBUG.
Issue: SPR-8645
CGLIB 3 has been released in order to depend on ASM 4, which Spring now
depends on internally (see previous commit).
This commit eliminates spring-beans' optional dependency on cglib-nodep
v2.2 and instead repackages net.sf.cglib => org.springframework.cglib
much in the same way we have historically done with ASM.
This change is beneficial to users in several ways:
- Eliminates the need to manually add CGLIB to the application
classpath; especially important for the growing number of
@Configuration class users. Java-based configuration functionality,
along with proxy-target-class and method injection features now
work 'out of the box' in Spring 3.2.
- Eliminates the possibility of conflicts with other libraries that
may dependend on differing versions of CGLIB, e.g. Hibernate
3.3.1.ga and its dependency on CGLIB 2.1.3 would easily cause a
conflict if the application were depending on CGLIB 3 for
Spring-related purposes.
- Picks up CGLIB 3's changes to support ASM 4, meaning that CGLIB is
that much less likely to work well in a Java 7 environment due to
ASM 4's support for transforming classes with invokedynamic
bytecode instructions.
On CGLIB and ASM:
CGLIB's own dependency on ASM is also transformed along the way to
depend on Spring's repackaged org.springframework.asm, primarily to
eliminate unnecessary duplication of ASM classfiles in spring-core and
in the process save around 100K in the final spring-core JAR file size.
It is coincidental that spring-core and CGLIB currently depend on the
exact same version of ASM (4.0), but it is also unlikely to change any
time soon. If this change does occur and versions of ASM drift, then
the size optimization mentioned above will have to be abandoned. This
would have no compatibility impact, however, so this is a reasonable
solution now and for the forseeable future.
On a mysterious NoClassDefFoundError:
During the upgrade to CGLIB 3.0, Spring test cases began failing due to
NoClassDefFoundErrors being thrown from CGLIB's DebuggingClassWriter
regarding its use of asm-util's TraceClassVisitor type. previous
versions of cglib-nodep, particularly 2.2, did not cause this behavior,
even though cglib-nodep has never actually repackaged and bundled
asm-util classes. The reason for these NoClassDefFoundErrors occurring
now is still not fully understood, but appears to be due to subtle JVM
bytecode preverification rules. The hypothesis is that due to minor
changes in DebuggingClassWriter such as additional casts, access to
instance variables declared in the superclass, and indeed a change in
the superclass hierarchy, preverification may be kicking in on the
toByteArray method body, at which point the reference to the missing
TraceClassVisitor type is noticed and the NCDFE is thrown. For this
reason, a dummy implementation of TraceClassVisitor has been added to
spring-core in the org.springframework.asm.util package. This class
simply ensures that Spring's own tests never result in the NCDFE
described above, and more importantly that Spring's users never
encounter the same.
Other changes include:
- rename package-private Cglib2AopProxy => CglibAopProxy
- eliminate all 'cglibAvailable' checks, warnings and errors
- eliminate all 'CGLIB2' language in favor of 'CGLIB'
- eliminate all mention in reference and java docs of needing to add
cglib(-nodep) to one's application classpath
Issue: SPR-9669
ASM 4.0 is generally compatibile with Java 7 classfiles, particularly
including 'invokedynamic' instructions. This is important when
considering that Spring's component-scanning support is internally
ASM-based and it is increasingly likely that component classes having
invokedynamic instructions may be encountered and read by ASM.
This upgrade, then, is primarily preventive in nature.
Changes include:
- upgrade from ASM 2.2.3 to ASM 4.0
- adapt to ASM API changes as necessary throughout spring-core,
resulting in no impact to the public Spring API.
- remove dedicated spring-asm module
- use new :spring-core:asmRepackJar task to repackage
org.objectweb.asm => org.springframework.asm as per usual and write
repackaged classes directly into spring-core jar
The choice to eliminate the spring-asm module altogether and instead
inline the repackaged classes directly into spring-core is first to
eliminate an otherwise unnecessary second jar. spring-core has a
non-optional dependency on spring-asm meaning it is always on the
application classpath. This change simplifies that situation by
consoliding two jars into one. The second reason for this choice is in
anticipation of upgrading CGLIB to version 3 and inlining it into
spring-core as well. See subsequent commit for details.
Issue: SPR-9669
JarJar 1.3 now uses ASM 4 in order to be compatible with Java 7
'invokedynamic' instructions. This is not an immediate concern for
the classes that we use JarJar to repackage and transform, but is a
timely upgrade in anticipation of the subsequent commits in which we
upgrade Spring's own dependency on ASM from 2.2.3 to 4.0 and Spring's
dependency on CGLIB from 2.2 to 3.0 (which in turn depends on ASM 4.0).
See https://code.google.com/p/jarjar/wiki/ChangeLog
Issue: SPR-9669
Attempting to register a custom MethodFilter with a
StandardEvaluationContext after invoking setMethodResolvers() with a
custom list of MethodResolver instances results in a
NullPointerException. Based on the current documentation in
StandardEvaluationContext it is unclear what the expected behavior
should be, but either the implementation is broken, or the use case is
unsupported. In either case, allowing a NullPointerException to be
thrown is inappropriate.
This commit documents the fact that the SpEL MethodFilter is intended to
be used with the ReflectiveMethodResolver. Furthermore,
StandardEvaluationContext.registerMethodFilter() now throws an
IllegalStateException if the user attempts to set a filter after having
registered a custom set of resolvers.
Issue: SPR-9621
The Spring Expression Language currently supports nested single quotes
within expressions but not nested double quotes.
The SpEL tokenizer has been modified to support nested double quotes in
the same way it supports single quotes. A sequence of two double quotes
will now be replaced by one when evaluated.
Extra error handling has also been added to report when invalid escaping
is encountered, since SpEL does not support escaping with backslash.
Issue: SPR-9620
SpEL typically supports logical operators for boolean expressions
consistent with standard Java language syntax. However, the operators
for logical AND and logical OR are currently only supported as textual
operators. In other words, SpEL does not support the use of && and || as
logical operators.
The SpEL tokenizer has now been modified to recognize && and || as
symbolic boolean operators. The parser has been modified to allow the
use of either the textual or symbolic operators.
Issue: SPR-9614
- renamed resolveParameterizedReturnType() to
resolveReturnTypeForGenericMethod()
- fleshed out Javadoc for resolveReturnType() and
resolveReturnTypeForGenericMethod() regarding declaration of formal
type variables
- improved wording in log statements and naming of local variables
within resolveReturnTypeForGenericMethod()
Issue: SPR-9493
Prior to this commit null literals in SpEL expressions had to be
specified as "null" (i.e., all lowercase).
With this commit null literals in SpEL expressions are interpreted in a
case-insensitive manner, analogous to the current support for boolean
literals.
Issue: SPR-9613
As a result of the refactoring, the AsyncContext dispatch mechanism is
used much more centrally. Effectively every asynchronously processed
request involves one initial (container) thread, a second thread to
produce the handler return value asynchronously, and a third thread
as a result of a dispatch back to the container to resume processing
of the asynchronous resuilt.
Other updates include the addition of a MockAsyncContext and support
of related request method in the test packages of spring-web and
spring-webmvc. Also an upgrade of a Jetty test dependency required
to make tests pass.
Issue: SPR-9433
When attempting to parse an Integer literal expression such as
42.toString(), SpEL currently throws a SpelParseException with a message
similar to: "EL1041E:(pos 3): After parsing a valid expression, there is
still more data in the expression: 'toString'". The problem here is that
'3.' is currently considered a valid number (including the dot).
However, SpEL succeeds at parsing an equivalent expression for a Double
literal such as 3.14.isInfinite().
To address this issue, the SpEL Tokenizer no longer consumes the
trailing '.' on an integer as part of the integer. So '3.foo()' will now
be parsed as '3' '.' 'foo()' and not '3.' 'foo()' -- which was what
prevented parsing of method invocations on integers. To keep the change
simple, the parser will no longer handle real numbers of the form
'3.e4'. From now on they must include the extra 0 (i.e., '3.0e4').
Issue: SPR-9612
Recently new utility methods were added to JdbcTestUtils, and a
JdbcTemplate was introduced in abstract transactional base classes in
the TestContext framework. This presents an easy opportunity to make
these new utility methods available as convenience methods in the base
test classes.
This commit introduces new countRowsInTableWhere() and dropTables()
convenience methods in the abstract transactional base classes in the
TestContext framework. These new methods internally delegate to methods
of the same names in JdbcTestUtils.
Issue: SPR-9665
Since Spring 2.5, the abstract transactional base classes in the
TestContext framework have defined and delegated to a protected
SimpleJdbcTemplate instance variable; however, SimpleJdbcTemplate has
deprecated since Spring 3.1. Consequently, subclasses of
AbstractTransactionalJUnit4SpringContextTests and
AbstractTransactionalTestNGSpringContextTests that use this instance
variable suffer from seemingly unnecessary deprecation warnings.
This commit addresses this issue by introducing a protected JdbcTemplate
instance variable in abstract transactional base classes to replace the
use of the existing SimpleJdbcTemplate. Furthermore, the existing
simpleJdbcTemplate instance variable has been deprecated, and utility
methods in the affected base classes now delegate to JdbcTestUtils
instead of the now deprecated SimpleJdbcTestUtils.
Issue: SPR-8990
Several static utility methods in SimpleJdbcTestUtils accept an instance
of SimpleJdbcTemplate as an argument; however, SimpleJdbcTemplate has
been deprecated since Spring 3.1 in favor of simply using JdbcTemplate
which now also supports Java 5 language constructs such as var-args.
Consequently, use of such methods from SimpleJdbcTestUtils results in
deprecation warnings without an equivalent API to migrate to.
This commit addresses this issue by migrating all existing methods in
SimpleJdbcTestUtils to JdbcTestUtils. The migrated methods now accept an
instance of JdbcTemplate as an argument, thereby avoiding the
deprecation warnings but maintaining semantic compatibility with the
functionality previous available in SimpleJdbcTestUtils.
In addition, this commit also introduces two new methods:
- countRowsInTableWhere(): counts the rows in a given table, using
a provided `WHERE` clause
- dropTables(): drops the tables with the specified names
Issue: SPR-9235
For legacy reasons, a MockEnvironment implementation already exists in multiple places within Spring's test suite; however, it is not available to the general public.
This commit promotes MockEnvironment to a first-class citizen in the spring-test module, alongside the existing MockPropertySource.
In addition, the following house cleaning has been performed.
- deleted MockPropertySource from the spring-expression module
- deleted MockEnvironment from the "spring" integration testing module
- updated test copies of MockPropertySource and MockEnvironment
- documented MockEnvironment and MockPropertySource in the testing
chapter of the reference manual
Issue: SPR-9492
Currently the Spring TestContext Framework looks up a
PlatformTransactionManager bean named "transactionManager". The exact
name of the bean can be overridden via @TransactionConfiguration or
@Transactional; however, the bean will always be looked up 'by name'.
The TransactionManagementConfigurer interface that was introduced in
Spring 3.1 provides a programmatic approach to specifying the
PlatformTransactionManager bean to be used for annotation-driven
transaction management, and that bean is not required to be named
"transactionManager". However, as of Spring 3.1.2, using the
TransactionManagementConfigurer on a @Configuration class has no effect
on how the TestContext framework looks up the transaction manager.
Consequently, if an explicit name or qualifier has not been specified,
the bean must be named "transactionManager" in order for a transactional
integration test to work.
This commit addresses this issue by refactoring the
TransactionalTestExecutionListener so that it looks up and delegates to
a single TransactionManagementConfigurer as part of the algorithm for
determining the transaction manager.
Issue: SPR-9604
TransactionalTestExecutionListener currently requires that the
PlatformTransactionManager bean be named "transactionManager" by
default. Otherwise, the bean name can only be overridden via the
transactionManager attribute of @TransactionConfiguration or the value
attribute of @Transactional.
However, if there is only a single PlatformTransactionManager in the
test's ApplicationContext, then the requirement to specify the exact
name of that bean (or to name it exactly "transactionManager") is often
superfluous.
This commit addresses this issue by refactoring the
TransactionalTestExecutionListener so that it is comparable to the
algorithm for determining the transaction manager used in
TransactionAspectSupport for "production" code. Specifically, the TTEL
now uses the following algorithm to retrieve the transaction manager.
- look up by type and qualifier from @Transactional
- else, look up by type and explicit name from
@TransactionConfiguration
- else, look up single bean by type
- else, look up by type and default name from @TransactionConfiguration
Issue: SPR-9645
Currently the getNamedDispatcher(String) method of MockServletContext
always returns null. This poses a problem in certain testing scenarios
since one would always expect at least a default Servlet to be present.
This is specifically important for web application tests that involve
the DefaultServletHttpRequestHandler which attempts to forward to the
default Servlet after retrieving it by name. Furthermore, there is no
way to register a named RequestDispatcher with the MockServletContext.
This commit addresses these issues by introducing the following in
MockServletContext.
- a new defaultServletName property for configuring the name of the
default Servlet, which defaults to "default"
- named RequestDispatchers can be registered and unregistered
- a MockRequestDispatcher is registered for the "default" Servlet
automatically in the constructor
- when the defaultServletName property is set to a new value the
the current default RequestDispatcher is unregistered and replaced
with a MockRequestDispatcher for the new defaultServletName
Issue: SPR-9587
Usually this request attribute is set for all sub-classes of
AbstractUrlHandlerMapping and therefore whenever
AnnotationMethodHandlerAdapter is used. However, having a
default value to fall back on in AnnotationMethodHandlerAdapter
is still appropriate in general and also considering the Javadoc
of HandlerMapping.INTROSPECT_TYPE_LEVEL_MAPPING.
Issue: SPR-9629
The MVC Java config and the MVC namespace now support options to
configure content negotiation. By default both support checking path
extensions first and the "Accept" header second. For path extensions
.json, .xml, .atom, and .rss are recognized out of the box if the
Jackson, JAXB2, or Rome libraries are available. The ServletContext
and the Java Activation Framework may be used as fallback options
for path extension lookups.
Issue: SPR-8420
After this change each call stack level pushes and pops an async
Callable to ensure the AsyncExecutionChain is in sync with the
call stack. Before this change, a controller returning a "forward:"
prefixed string caused the AsyncExecutionChain to contain a
extra Callables that did not match the actual call stack.
Issue: SPR-9611
Previously MockHttpServletRequest#sendRedirect did not set the HTTP status
or the Location header. This does not conform to the HttpServletRequest
interface.
MockHttpServletRequest will now:
- Set the HTTP status to 302 on sendRedirect
- Set the Location header on sendRedirect
- Ensure the Location header and getRedirectedUrl are kept in synch
Issue: SPR-9594
Update section on exception handling in Spring MVC chapter to include
more guidance on exception handling when implementing a REST API.
Issue: SPR-9290
Previously DefaultHandlerExceptionResolver did not handle BindException
but after this change it does. A BindException is raised when an
@ModelAttribute annotated argument is not followed by a BindingResult
argument. Hence this is unlikely to affect browser rendering.
For programmatic clients however this change ensures an unhandled
BindException is at least turned into a 400 error.
Issue: SPR-9310
The Atom/RSS message converters are now registered ahead of the
Jackson and the JAXB2 message converters by default. Since the Atom
and RSS converters convert to and from very specific object types
Feed and Channel respectively, that shouldn't introduce any regressions
and will work more intuitively when the requested media type is "*/*".
Issue: SPR-9054
Previously only **/*.java sources files were included in the sources
jars. This is not ideal for the spring-aspects jar nor does it match
prior versions of the sources jars.
Now **/*.aj files are included in addition to the **/*.java files.
Issue: SPR-9576
Before this change @ExceptionHandler methods could be located in and
apply locally within a controller. The change makes it possible to have
such methods applicable globally regardless of the controller that
raised the exception.
The easiest way to do that is to add them to a class annotated with
`@ExceptionResolver`, a new annotation that is also an `@Component`
annotation (and therefore works with component scanning). It is also
possible to register classes containing `@ExceptionHandler` methods
directly with the ExceptionHandlerExceptionResolver.
When multiple `@ExceptionResolver` classes are detected, or registered
directly, the order in which they're used depends on the the `@Order`
annotation (if present) or on the value of the order field (if the
Ordered interface is implemented).
Issue: SPR-9112
Prior to this change, PropertySourcesPropertyResolver (and therefore
all AbstractEnvironment) implementations failed to resolve nested
placeholders as in the following example:
p1=v1
p2=v2
p3=${v1}:{$v2}
Calls to PropertySource#getProperty for keys 'p1' and 'v1' would
successfully return their respective values, but for 'p3' the return
value would be the unresolved placeholders. This behavior is
inconsistent with that of PropertyPlaceholderConfigurer.
PropertySourcesPropertyResolver #getProperty variants now resolve any
nested placeholders recursively, throwing IllegalArgumentException for
any unresolvable placeholders (as is the default behavior for
PropertyPlaceholderConfigurer). See SPR-9569 for an enhancement that
will intoduce an 'ignoreUnresolvablePlaceholders' switch to make this
behavior configurable.
This commit also improves error output in
PropertyPlaceholderHelper#parseStringValue by including the original
string in which an unresolvable placeholder was found.
Issue: SPR-9473, SPR-9569
Before this change HandlerMethod used ClassUtils.getUserClass(Class<?>)
to get the real user class, and not one generated by CGlib. However it
failed to that under all circumstances. This change fixes that.
Issue: SPR-9490
Before this change the StringHttpMessageConverter used a fixed charset
"ISO-8859-1" if the requested content type did not specify one. This
change adds a defaultCharset field and a constructor to configure it in
StringHttpMessageConverter.
Issue: SPR-9487
Before this change the HandlerExecitionChain logged errors each time a
an AsyncHandlerInterceptor returned a null async Callable, a condition
which is acceptable.
SPR-9524
Ensure that NonClosingOutputStream calls with a byte array call the
corresponding methods of the underlying OutputStream rather than
relying on the default NonClosingOutputStream implementation, which
writes one bte at a time. This significantly improves performance.
Issues: SPR-9530
@Async executor qualification has been backported to 3.1.2. This commit
updates all @since tags appropriately, as well as carrying over the
changes backported to the spring-task-3.1 schema.
Issue: SPR-6847, SPR-9443
Return an empty map when there are no path variables, rather than
raising an exception. This is consistent with similar resolvers for
extracting headers and request parameters.
Issue: SPR-9289
Following the introduction of ContentNegotiationManager that allows,
among other things, to configure the file extensions to use for content
negotiation, this change adds "smart" suffix pattern match that matches
against the configured file extensions only rather than against any
extension.
Given the request mapping "/jobs/{jobName}" and one configured file
extension ("json"), a request for "/jobs/my.job" will select the
pattern "/jobs/{jobName}" while a request for "/jobs/my.job.json" will
select the pattern "/jobs/{jobName}.json". Previously, both requests
would have resulted in the pattern "/jobs/{jobName}.*".
Issue: SPR-7632, SPR-8474
The exact text above the "Staying in touch" section caused "Staying in
touch" to lose it's formatting as a second-level heading. Adding
" for details" to the sentence above works around the problem.
The HTTP PATCH method is now supported whereever HTTP methods are used.
Annotated controllers can be mapped to RequestMethod.PATCH.
On the client side the RestTemplate execute(..) and exchange(..)
methods can be used with HttpMethod.PATCH. In terms of HTTP client
libraries, Apache HttpComponents HttpClient version 4.2 or later is
required (see HTTPCLIENT-1191). The JDK HttpURLConnection does not
support the HTTP PATCH method.
Issue: SPR-7985
Introduced ContentNeogtiationStrategy for resolving the requested
media types from an incoming request. The available implementations
are based on path extension, request parameter, 'Accept' header,
and a fixed default content type. The logic for these implementations
is based on equivalent options, previously available only in the
ContentNegotiatingViewResolver.
Also in this commit is ContentNegotiationManager, the central class to
use when configuring content negotiation options. It accepts one or
more ContentNeogtiationStrategy instances and delegates to them.
The ContentNeogiationManager can now be used to configure the
following classes:
- RequestMappingHandlerMappingm
- RequestMappingHandlerAdapter
- ExceptionHandlerExceptionResolver
- ContentNegotiatingViewResolver
Issue: SPR-8410, SPR-8417, SPR-8418,SPR-8416, SPR-8419,SPR-7722
PropertySourcesPropertyResolver#containsProperty now
calls #containsProperty on each underlying PropertySource instead of
calling #getProperty and checking for null.
Issue: SPR-9529
The reference manual currently documents the wrong file name for the
default data SQL script used by EmbeddedDatabaseBuilder. In addition,
the testing chapter of the reference manual does not link to the testing
section of the JDBC chapter.
- Updated the "Testing data access logic with an embedded database"
section of the reference manual appropriately.
- Added a new paragraph to the "JDBC Testing Support" section of the
testing chapter which cross references the "Testing data access logic
with an embedded database" section.
Issue: SPR-9467
Commit aa415d7c0c introduced
JacksonObjectMapperFactoryBean and associated tests, but with Windows
(CRLF) line endings instead of the conventional Unix (LF) line endings.
This commit converts these files to LF endings using the handy
`dos2unix` utility.
Issue: SPR-9125
Currently, if a factory method is parameterized and the corresponding
variable types are declared on the method itself instead of on the
enclosing class or interface, Spring always predicts the return type to
be Object, even if the return type can be explicitly inferred from the
method signature and supplied arguments (which are available in the bean
definition).
This commit introduces a new resolveParameterizedReturnType() method in
GenericTypeResolver that attempts to infer the concrete type for the
generic return type of a given parameterized method, falling back to the
standard return type if necessary. Furthermore,
AbstractAutowireCapableBeanFactory now delegates to
resolveParameterizedReturnType() when predicting the return type for
factory methods.
resolveParameterizedReturnType() is capable of inferring the concrete
type for return type T for method signatures similar to the following.
Such methods may potentially be static. Also, the formal argument list
for such methods is not limited to a single argument.
- public <T> T foo(Class<T> clazz)
- public <T> T foo(Object obj, Class<T> clazz)
- public <V, T> T foo(V obj, Class<T> clazz)
- public <T> T foo(T obj)
Issue: SPR-9493
The readme is heavy on links and hard to read in source form when using
typical inline Markdown links. The following changes have been made to
increase readability.
- Wrap lines at 80 characters
- Use 'implicit link name' shortcut syntax as described at [1]
- Add link to 'spring-mvc' Stack Overflow tag as well
- Add link to new 'lifecycle of an issue' wiki doc
[1]: http://daringfireball.net/projects/markdown/syntax
Some Spring Framework users and teams cannot use transitive dependency
management tools like Maven, Gradle and Ivy. For them, a `distZip` task
has been added to allow for creating a Spring Framework distribution
from source that includes all optional and required runtime
dependencies for all modules of the framework.
This 'dist-with-deps' zip is not published to the SpringSource
repository nor to the SpringSource community download page. It is
strictly an optional task introduced as a convenience to the users
mentioned above.
Detailed instructions for building this zip locally have been added to
the wiki and the README has been updated with a link to that new doc.
Issue: SPR-6575
The BeanFactory makes it easier to configure a customized Jackson
ObjectMapper (for example enable/disable certain features).
This bean factory is usually used with
MappingJacksonHttpMessageConverter or MappingJacksonJsonView.
See JavaDoc for examples.
Issue: SPR-9125
Previously MediaType could only parse double-quoted parameters without
raising an IllegalArgumentException. Now parameters can also be
single-quoted.
Issue: SPR-8917
The failure of the conversion service is not fatal, but the check that
was in there (line 248) was inadequate to detect the cases that could
already be handled by the default property editors. This code path
was also not tested anywhere in spring-beans tests until now.
HttpStatus cannot be created with an unknown status code. If a server
returns a status code that's not in the HttpStatus enum values, an
IllegalArgumentException is raised. Rather than allowing it to
propagate as such, this change ensures the actual exception raised is
a RestClientException.
Issue: SPR-9406
A recent commit made aopalliance optional for spring-aop, while
continuing to require it for spring-tx. On review, this is probably
overly aggressive, and for convenience aopalliance should remain
required for spring-aop. There are use cases for which aopalliance is
indeed optional, but core functionality such as <aop:scoped-proxy>
should never result in a ClassNotFoundException.
This commit returns the aopalliance dependency for spring-aop to
required status, and also explicitly notes the same dependency in other
modules that compile directly against aopalliance types.
Issue: SPR-9501
The junit:junit Maven artifact includes a bundled version of hamcrest
core. For projects that depend on later versions of hamcrest this causes
significant issues in terms of dependency management.
The spring-test module now depends on junit:junit-dep, thus allowing
developers to better manage their test dependencies on a more fine
grained level.
Also tidied up dependency issues regarding hamcrest-core and
hamcrest-all across the build.
Issue: SPR-6966
This commit introduces a test suite (Spr8849Tests) that demonstrates
the claims made in SPR-8849.
Specifically, if <jdbc:embedded-database id="xyz" /> is used to create
an embedded HSQL database in an XML configuration file and that
configuration file is imported in different sets of configuration files
that are used to load ApplicationContexts for different integration
tests, the embedded database will be initialized multiple times using
any nested <jdbc:script /> elements. If such a script is used to create
a table, for example, subsequent attempts to initialize the database
named "xyz" will fail since an embedded database named "xyz" already
exists in the JVM.
As a work-around, this test suite uses a SpEL expression to generate a
random string for each embedded database instance:
id="#{T(java.util.UUID).randomUUID().toString()}"
See the Javadoc in Spr8849Tests for further information.
Issue: SPR-8849
Previously, DatabasePopulatorUtils#execute looked up a Connection from
the given DataSource directly which resulted in the executed statements
not being executed against a transactional connection (if any) which in
turn resulted in the statements executed by the populator potentially
not being rolled back.
Now DataSourceUtils#getConnection is used to transparently take part in
any active transaction and #releaseConnection is used to ensure the
connection is closed if appropriate.
Issue: SPR-9457
Default HTTP error exceptions thrown from RestTemplate now include
response headers in addition to the response body. In particular, this
enables inspection of the Content-Type header allowing manual
deserialization of the response body without guessing as to the content
type.
- introduce HttpStatusCodeException#getResponseHeaders
- add constructor with headers param for HttpStatusCodeException,
HttpClientErrorException and HttpServerErrorException
- preserve exsisting constructor signatures
- mark HttpHeaders as Serializable
- generate new serialVersionUID where needed
Issue: SPR-7938
The following style updates have been made in anticipation of
substantive changes in subsequent commits:
- organize imports
- correct whitespace errors (leading spaces in code, tabs in Javadoc)
- wrap Javadoc at 90 chars; make imperative ("Return" vs. "Returns")
- use conventional constructor argument wrapping
A serialVersionUID has also been added to RestClientException and its
ResourceAccessException subclass for consistency with the rest of that
same exception hierarchy.
Issue: SPR-7938
- Explicitly specify compile-time dependencies on other spring-*
modules, primarily for accuracy in pom generation and ensuring
minimal dependencies for users of spring-aspects.
- Remove use of p: namespace from annotation-cache-aspectj.xml to
avoid parser-related test failures under Eclipse (likely due to
classpath differences between Gradle and Eclipse).
The spring-intstrument jar should have a 'Premain-Class:' manifest
entry in order to enable use as a Java agent. This entry was present in
versions 3.1.1 and earlier, but due to build infrastructure changes
starting in 3.2.x this entry was missed. It is now back in place as
expected.
Issue: SPR-9458
Gradle-generated poms thoroughly tested against 3.1.1 versions, with an
eye toward making as many spring-* dependencies optional as possible.
All spring-* modules now declare a Gradle dependency on any other
spring-* module where there is a direct compile-time usage of the
sources in that module. Previously, dependency declarations were
minimal, letting transitive resolution do most of the work. However,
this creates less than ideal poms and is generally not very
informative.
So for example, spring-jdbc uses spring-core, spring-beans and
spring-tx classes directly. Therefore it has the following declarations:
compile project(":spring-core")
compile project(":spring-beans")
compile project(":spring-tx")
spring-core depends on spring-asm, but spring-jdbc does not use
spring-asm classes directly. Therefore spring-jdbc does not declare a
dependency on spring-asm. Transitive resolution is fine in such a case.
As for optional dependencies, it is a matter of degrees what
constitutes optional. A rule of thumb is whether there are legitimate
and likely use cases in which the module can be used without needing
the dependency. spring-jdbc has only one compile-time dependency on
spring-context classes, and that's in JndiDataSourceLookup. It is
certainly reasonable to imagine using spring-jdbc without JNDI,
therefore the spring-context dependency is declared optional as
follows:
compile(project(":spring-context"), optional) // for JndiDataSourceLookup
In Spring 3.1 the spring-test Maven artifact did not have a required
dependency on spring-core, but there is practically no part of
spring-test that can be used without spring-core. Most test utilities
that are intended to be stand-alone utilities in fact use utility
classes from spring-core (e.g., ReflectionTestUtils). Even some of the
web mocks/stubs use spring-core (e.g., DelegatingServletInputStream).
In addition, the current Gradle build configuration for the spring-test
module is very simplistic -- in that it does not explicitly list any
optional dependencies such as the Servlet and Portlet APIs -- and it
defines a 'compile' dependency on spring-webmvc-portlet.
The resulting Maven dependencies in the generated POM are therefore not
what a typical consumer of the spring-test artifact would reasonably
expect.
To address these issues, the Gradle build configuration for the
spring-test module now explicitly defines the following 'compile'
dependencies:
- spring-core
- spring-webmvc, optional
- spring-webmvc-portlet, optional
- junit, optional
- testng, optional
- servlet-api, optional
- jsp-api, optional
- portlet-api, optional
- activation, provided
The only required dependency is now spring-core; all other dependencies
are 'optional'.
Issue: SPR-8861
Prior to this change, by-type lookups using DLBF#getBeanNamesForType
required traversal of all bean definitions within the bean factory
in order to inspect their bean class for assignability to the target
type. These operations are comparatively expensive and when there are a
large number of beans registered within the container coupled with a
large number of by-type lookups at runtime, the performance impact can
be severe. The test introduced here demonstrates such a scenario clearly.
This performance problem is likely to manifest in large Spring-based
applications using non-singleton beans, particularly request-scoped
beans that may be created and wired many thousands of times per second.
This commit introduces a simple ConcurrentHashMap-based caching strategy
for by-type lookups; container-wide assignability checks happen only
once on the first by-type lookup and are afterwards cached by type
with the values in the map being an array of all bean names assignable
to that type. This means that at runtime when creating and autowiring
non-singleton beans, the cost of by-type lookups is reduced to that of
ConcurrentHashMap#get.
Issue: SPR-6870
Previously (since Spring 3.1.1) RecursiveAnnotationAttributesVisitor
logs at level WARN when ASM parsing encounters an annotation or an (enum
used within an annotation) that cannot be classloaded. This is not
necessarily indicative of an error, e.g. JSR-305 annotations such as
@Nonnull may be used only for static analysis purposes, but because
these annotations have runtime retention, they remain present in the
bytecode. Per section 9.6.1.2 of the JLS, "An annotation that is present
in the binary may or may not be available at run-time via the reflective
libraries of the Java platform."
This commit lowers the log level of these messages from warn to debug,
but leaves at warn level other messages dealing with the ability
reflectively read enum values from within annotations.
Issue: SPR-9233
The following syntax is now supported
<beans profile="p1,!p2">
@Profile("p1", "!p2")
indicating that the <beans> element or annotated component should
be processed only if profile 'p1' is active or profile 'p2' is not
active.
Issue: SPR-8728
Changes introduced in Spring 3.1 for Environment support inadvertently
established a cyclic dependency between the
org.springframework.web.context and
org.springframework.web.context.support packages, specifically through
web.context.ContextLoader's invocation of
web.context.support.WebApplicationContextUtils#initServletPropertySources.
This commit introduces ConfigurableWebEnvironment to break this cyclic
dependency. All web.context.ConfigurableWebApplicationContext types now
return web.context.ConfigurableWebEnvironment from their #getEnvironment
methods; web.context.support.StandardServletEnvironment now implements
ConfigurableWebEnvironment and makes the call to
web.context.support.WebApplicationContextUtils#initServletPropertySources
within its implementation of #initPropertySources. This means that
web.context.ContextLoader now invokes
web.context.ConfigurableWebEnvironment#initPropertySources instead of
web.context.support.WebApplicationContextUtils#initServletPropertySources
and thus the cycle is broken.
Issue: SPR-9439
Prior to this change, AbstractApplicationContext#setParent replaced the
child context's Environment with the parent's Environment if available.
This has the negative effect of potentially changing the type of the
child context's Environment, and in any case causes property sources
added directly against the child environment to be ignored. This
situation could easily occur if a WebApplicationContext child had a
non-web ApplicationContext set as its parent. In this case the parent
Environment type would (likely) be StandardEnvironment, while the child
Environment type would (likely) be StandardServletEnvironment. By
directly inheriting the parent environment, critical property sources
such as ServletContextPropertySource are lost entirely.
This commit introduces the concept of merging an environment through
the new ConfigurableEnvironment#merge method. Instead of replacing the
child's environment with the parent's,
AbstractApplicationContext#setParent now merges property sources as
well as active and default profile names from the parent into the
child. In this way, distinct environment objects are maintained with
specific types and property sources preserved. See #merge Javadoc for
additional details.
Issue: SPR-9444, SPR-9439
@EnableSpringConfigured and its @Import'ed
SpringConfiguredConfiguration @Configuration class inadvertently
established a package cycle between beans.factory.aspectj and
context.annotation due to SpringConfiguredConfiguration's
dependency on annotations such as @Configuration, @Bean and @Role.
This commit fixes this architecture bug by moving
@EnableSpringConfigured and SpringConfiguredConfiguration from the
beans.factory.aspectj package to the context.annotation package where
they belong.
This change is assumed to be very low impact as @EnableSpringConfigured
was introduced in 3.1.0 and relocation is happening as quickly as
possible in 3.1.2. @EnableSpringConfigured is assumed to be infrequently
used at this point, and for those that are the migration path
is straightforward. When upgrading from Spring 3.1.0 or 3.1.1, update
import statements in any affected @Configuration classes to reflect the
new packaging.
Issue: SPR-9441
Commit 096693c46f refactored and
deprecated TransactionAspectUtils, moving its #qualifiedBeanOfType
and related methods into BeanFactoryUtils. This created a package cycle
between beans.factory and beans.factory.annotation due to use of the
beans.factory.annotation.Qualifier annotation in these methods.
This commit breaks the package cycle by introducing
beans.factory.annotation.BeanFactoryAnnotationUtils and moving these
@Qualifier-related methods to it. It is intentionally similar in name
and style to the familiar BeanFactoryUtils class for purposes of
discoverability.
There are no backward-compatibilty concerns associated with this change
as the cycle was introduced, caught and now fixed before a release.
Issue: SPR-6847
As of Spring 3.1 URI variables can be used for data binding purposes in
addition to request parameters (including query string and form params)
In some cases URI variables and request params can overlap (e.g. form
contains a child entity with an entityId as hidden form input while the
URI contains the entityId of the parent entity) and that can lead to
surprises if the application already exists.
This change ensures that request parameters are used first and URI
vars are added only if they don't overlap. Ideally however an
application should not use the same uri variable name as the name of
a request parameter where they don't refer to the same value.
Issue: SPR-9349
java.util.concurrent's ScheduledExecutorService and its #schedule*
methods allow for an 'initialDelay' parameter in milliseconds.
Similarly, Spring's TaskExecutor abstraction allows for a concrete
'startTime' expressed as a Date. However, Spring's <task:scheduled> XML
element and @Scheduled annotation have, to date, not allowed for an
initial delay parameter that can be propagated down to the underlying
TaskScheduler/ScheduledExecutorService.
This commit introduces initial-delay and #initialDelay attributes to
task:scheduled and @Scheduled respectively, both indicating the number
of milliseconds to wait before the first invocation of the method in
question. Specifying a delay in this fashion is only valid in
conjunction with fixed-rate and fixed-delay tasks (i.e. not with cron
or trigger tasks).
The principal changes required to support these new attributes lie in
ScheduledTaskRegistrar, which previously supported registration of
tasks in the form of a Runnable and a Long parameter indicating (in the
case of fixed-rate and fixed-delay tasks), the interval with which the
task should be executed. In order to accommodate a third (and optional)
'initialDelay' parameter, the IntervalTask class has been added as a
holder for the Runnable to be executed, the interval in which to run
it, and the optional initial delay. For symmetry, a TriggerTask and
CronTask have also been added, the latter subclassing the former. And a
'Task' class has been added as a common ancestor for all the above.
One oddity of the implementation is in the naming of the new
setters in ScheduledTaskRegistrar. Prior to this commit, the setters
were named #setFixedDelayTasks, #setFixedRateTasks, etc, each accepting
a Map<Runnable, long>. In adding new setters for each task type, each
accepting a List<IntervalTask>, List<CronTask> etc, naturally the
approach would be to use method overloading and to introduce methods
of the same name but with differing parameter types. Unfortunately
however, Spring does not support injection against overloaded methods
(due to fundamental limitations of the underlying JDK Introspector).
This is not a problem when working with the ScheduledTaskRegistrar
directly, e.g. from within a @Configuration class that implements
SchedulingConfigurer, but is a problem from the point of view of the
ScheduledTasksBeanDefinitionParser which parses the <task:scheduled>
element - here the ScheduledTaskRegistrar is treated as a Spring bean
and is thus subject to these limitations. The solution to this problem
was simply to avoid overloading altogether, thus the naming of the new
methods ending in "List", e.g. #setFixedDelayTasksList, etc. These
methods exist primarily for use by the BeanDefinitionParser and are
not really intended for use by application developers. The Javadoc for
each of the new methods makes note of this.
Issue: SPR-7022
In anticipation of substantive changes required to implement "initial
delay" support in the <task:scheduled> element and @Scheduled
annotation, the following updates have been made to the components and
infrastructure supporting scheduled task execution:
- Fix code style violations
- Fix compiler warnings
- Add Javadoc where missing, update to use {@code} tags, etc.
- Organize imports to follow conventions
This commit introduces three abstract WebApplicationInitializers, to be
used in the typical setup of a Spring-based web application.
- AbstractContextLoaderInitializer provides an abstract base class for
registering a ContextLoaderListener.
- AbstractDispatcherServletInitializer provides an abstract base class
for registering a DispatcherServlet, with an optional root context.
- AbstractAnnotationConfigDispatcherServletInitializer provides an
abstract base class for registering a DispatcherServlet and optional
ContextLoaderListener based on annotated (e.g. @Configuration)
classes.
Issue: SPR-9300
Prior to this change, Spring's @Async annotation support was tied to a
single AsyncTaskExecutor bean, meaning that all methods marked with
@Async were forced to use the same executor. This is an undesirable
limitation, given that certain methods may have different priorities,
etc. This leads to the need to (optionally) qualify which executor
should handle each method.
This is similar to the way that Spring's @Transactional annotation was
originally tied to a single PlatformTransactionManager, but in Spring
3.0 was enhanced to allow for a qualifier via the #value attribute, e.g.
@Transactional("ptm1")
public void m() { ... }
where "ptm1" is either the name of a PlatformTransactionManager bean or
a qualifier value associated with a PlatformTransactionManager bean,
e.g. via the <qualifier> element in XML or the @Qualifier annotation.
This commit introduces the same approach to @Async and its relationship
to underlying executor beans. As always, the following syntax remains
supported
@Async
public void m() { ... }
indicating that calls to #m will be delegated to the "default" executor,
i.e. the executor provided to
<task:annotation-driven executor="..."/>
or the executor specified when authoring a @Configuration class that
implements AsyncConfigurer and its #getAsyncExecutor method.
However, it now also possible to qualify which executor should be used
on a method-by-method basis, e.g.
@Async("e1")
public void m() { ... }
indicating that calls to #m will be delegated to the executor bean
named or otherwise qualified as "e1". Unlike the default executor
which is specified up front at configuration time as described above,
the "e1" executor bean is looked up within the container on the first
execution of #m and then cached in association with that method for the
lifetime of the container.
Class-level use of Async#value behaves as expected, indicating that all
methods within the annotated class should be executed with the named
executor. In the case of both method- and class-level annotations, any
method-level #value overrides any class level #value.
This commit introduces the following major changes:
- Add @Async#value attribute for executor qualification
- Introduce AsyncExecutionAspectSupport as a common base class for
both MethodInterceptor- and AspectJ-based async aspects. This base
class provides common structure for specifying the default executor
(#setExecutor) as well as logic for determining (and caching) which
executor should execute a given method (#determineAsyncExecutor) and
an abstract method to allow subclasses to provide specific strategies
for executor qualification (#getExecutorQualifier).
- Introduce AnnotationAsyncExecutionInterceptor as a specialization of
the existing AsyncExecutionInterceptor to allow for introspection of
the @Async annotation and its #value attribute for a given method.
Note that this new subclass was necessary for packaging reasons -
the original AsyncExecutionInterceptor lives in
org.springframework.aop and therefore does not have visibility to
the @Async annotation in org.springframework.scheduling.annotation.
This new subclass replaces usage of AsyncExecutionInterceptor
throughout the framework, though the latter remains usable and
undeprecated for compatibility with any existing third-party
extensions.
- Add documentation to spring-task-3.2.xsd and reference manual
explaining @Async executor qualification
- Add tests covering all new functionality
Note that the public API of all affected components remains backward-
compatible.
Issue: SPR-6847
In anticipation of substantive changes required to implement @Async
executor qualification, the following updates have been made to the
components and infrastructure supporting @Async functionality:
- Fix trailing whitespace and indentation errors
- Fix generics warnings
- Add Javadoc where missing, update to use {@code} tags, etc.
- Avoid NPE in AopUtils#canApply
- Organize imports to follow conventions
- Remove System.out.println statements from tests
- Correct various punctuation and grammar problems
TransactionAspectUtils contains a number of methods useful in
retrieving a bean by type+qualifier. These methods are functionally
general-purpose save for the hard coding of PlatformTransactionManager
class literals throughout.
This commit generifies these methods and moves them into
BeanFactoryUtils primarily in anticipation of their use by async method
execution interceptors and aspects when performing lookups for qualified
executor beans e.g. via @Async("qualifier").
The public API of TransactionAspectUtils remains backward compatible;
all methods within have been deprecated, and all calls to those methods
throughout the framework refactored to use the new BeanFactoryUtils
variants instead.
The reference manual previously did not mention the applicability of
JSR-250 lifecycle annotations within the TestContext framework. The
lacking documentation here has lead to misunderstandings of the support
provided for @PostConstruct and @PreDestroy in test classes.
The testing chapter of the reference manual has therefore been updated
to explicitly define the limited support for these annotations.
Also introduced Jsr250LifecycleTests for empirical verification of the
expected behavior.
Issue: SPR-4868
There is usually not need to put annotations on a WebDataBinder
argument in an `@InitBinder` method. However, the presence of any
annotation prevented the successful resolution of the argument.
This fix addresses the issue.
Issue: SPR-8946
Updated the "@Bean Lite Mode" section in order to properly document
scoping and lifecycle semantics.
Also fleshed out the discussion of the non-applicability of 'inter-bean
references' in lite mode.
Issue: SPR-9425
Introduced AtBeanLiteModeScopeTests integration tests to verify proper
scoping of beans created in 'lite' mode.
Updated comments in TACCWithoutACTests to better reflect the runtime
behavior for 'lite' @Bean methods.
Issue: SPR-9401
Previously, the <value> subelement of a map <entry> allowed one to
specify the type of a specific map entry value. This patch allows a
value-type attribute as well, such that instead of the following
syntax
<entry key="x-message-ttl">
<value type="java.lang.Long">100</value>
</entry>
<entry key="x-ha-policy" value="all" />
one can now use the more concise form
<entry key="x-message-ttl" value="100" value-type="java.lang.Long"/>
<entry key="x-ha-policy" value="all"/>
The new value-type attribute may be used at the <map> level as well,
indicating that all elements are of the same type.
Appropriate tests have been added exercising value-type at the <map> and
<entry> levels.
Issue: SPR-9249
Updated the testing chapter of the reference manual to refer to
'annotated classes' instead of 'configuration classes' where
appropriate.
Also revised the content and examples in the @ContextConfiguration
annotation section, mentioned Gradle, and reformatted the entire text.
Issue: SPR-9401
Several test methods in RequestResponseBodyMethodProcessorTests
are currently annotated with @Test(expected=…) and additionally contain:
fail("Expected exception");
This combination is superfluous, and the unnecessary fail() invocations
have therefore been removed.
When URL decoding is turned off in AbstractHandlerMapping, the
extracted path variables are also not encoded. Turning off URL decoding
may be necessary for request mapping to work correctly when the path
may contain the (encoded) special character '/'. At the same time there
is no good reason not to leave path variables encoded. This change
ensures path variables are encoded when URL decoding is turned off.
Issue: SPR-9098
Updated all Javadoc in the Spring TestContext Framework (TCF) to explain
and refer to 'annotated classes' instead of 'configuration classes'.
Specifically, @ContextConfiguration now explicitly defines what is meant
by 'annotated classes', and various other classes now refer to this
definition. Otherwise, the term 'configuration class' has simply been
replaced with 'annotated class'.
Also deleted cross references to deprecated JUnit 3.8 classes and
formatted Javadoc in general for greater readability.
Issue: SPR-9401
Reordered inline comments so that they now apply to current
state of the code.
Added logger entry in testlog4j.properties to avoid console
warning.
Issue: SPR-9417
A set of resolved placeholder references is used for circular
placeholder prevention. For complex property definitions this mechanism
would put property values with unresolved inner placeholder references
in the set, but would try to remove property values with placeholders
resolved, leaving the set in an invalid state and the mechanism broken.
This fix makes sure that the value that is put in the set is same one
that is removed from it, and by doing so avoids false positives in
reporting circular placeholders.
Issue: SPR-5369
This patch fixes several compiler warnings that do not point to code
problems. Two kinds of warnings are fixed. First in a lot of cases
@SuppressWarnings("unchecked") is used although there are no unchecked
casts happening. This seems to be a leftover from when the code base
was on Java 1.4, now that the code base was moved to Java 1.5 these are
no longer necessary. Secondly there some places where the raw types of
List and Class are used where there wildcard types (List<?> and
Class<?>) would work just as well without causing any raw type warnings.
These changes are beneficial particularly when working in Eclipse or
other IDEs because it reduces 'noise', helping to isolate actual
potential problems in the code.
The following changes have been made:
- remove @SuppressWarnings where no longer needed
- use wildcard types instead of raw types where possible
Prior to this change, SpEL would not allow the use of '[]' in
expressions like the following:
T(foo.Bar[])
This commit updates TypeReference and InternalSpelExpressionParser to
support this syntax, avoiding the need for workarounds like:
new foo.bar[0].class
Issue: SPR-9203
Even though the Javadoc for Constants#toCode and #toCodeForSuffix
specifies that a null value for the 'namePrefix' and 'nameSuffix'
parameters are respectively allowed, before this change passing a null
to either would result in a NullPointerException.
This change fixes constant name lookup for null values of these params
as if an empty string had been passed instead. This way of handling a
null value is consistent with the rest of Constants class API.
Issue: SPR-8278
Before this change JibxMarshallerTests would fail on Windows with an
error message explaining that JiBX compiler generated classes are not
found on the classpath for binding with name 'binding'. Tests would
execute well on Linux and OS X.
Actual root cause of this bug is found to be in JiBX 1.1.5 release that
is used to build Spring. The binding name can be explicitly specified in
JiBX binding file. If omitted, when generating classes the JiBX compiler
as fall-back mechanism tries to derive the binding name from the binding
file name. That logic had a bug which gets manifested when configured
binding file path has mixed Windows and *nix style file separators, as
in case of JibxMarshallerTests being executed on a Windows platform.
This commit resolves this issue by upgrading Spring's build from JiBX
1.1.5 to 1.2.3, as the bug mentioned was fixed in JiBX 1.2. See JIBX-441
for more details.
Issue: SPR-8360
Before this fix ReflectivePropertyAccessor was not able to find write
method for valid property name that has first character in lower case
and second character in upper case. Write method lookup would always
convert first character of property name to upper case which is not
compliant with JavaBean specification. As consequence this caused an
unwanted behavior in SpEL when obtaining values of expressions that
reference such JavaBean properties.
As of this change, write method lookup skips conversion of property
name first character to upper case when property name is longer than
one character and second character is in upper case. This also fixes
mentioned bug in SpEL value resolution.
Issue: SPR-9123
Previously, if the resolution of a ${...} placeholder resulted in a
valid URL for the location of a log4j properties/XML file, the URL
would ultimately be malformed by an unnecessary call to to
WebUtils#getRealPath.
The implementation of Log4jWebConfigurer#initLogging now eagerly
attempts SystemPropertyUtils#resolvePlaceholders before checking to see
if the location is a valid URL, and bypassing the call to
WebUtils#getRealPath if so.
Issue: SPR-9417
Previously, StringUtils#parseLocaleString would parse locale strings
having the same lowercase token for both language and country
incorrectly, e.g. 'tr_tr' would parse to 'tr_TR_tr' as opposed to the
expected 'tr_TR'.
This commit fixes this behavior by using using String#lastIndexOf
instead of String#indexOf when determining the location of the country
code token.
Issue: SPR-9420
Updated the class-level JavaDoc for @Bean to better explain the
semantics of 'lite' mode.
Renamed "Configuration Class Lite Mode" to "@Bean Lite Mode".
Added discussion of @DependsOn to the class-level JavaDoc.
Issue: SPR-9401
In AnnotationUtils#findAnnotation(Method, Class), the search for a
method annotation fails if:
- the original method does not have the annotation
- an abstract superclass does not have an equivalent method declared
- an interface implemented by the superclass has the method and
the annotation -> this should be found, but is not!
This happens because the try-catch block in #findAnnotation is too wide:
cl.getDeclaredMethod() can throw NoSuchMethodException and skip the
'#searchOnInterfaces' call prematurely.
The try-catch block was made narrower to allow #searchOnInterfaces to
be called even if the abstract class does not have the method declared
at all.
Issue: SPR-9342
Overhauled the class-level JavaDoc in @Bean:
- added h3 headers for greater clarity and readability
- mentioned 'prototype' semantics for lite mode
Issue: SPR-9401
Prior to this change, Spring's MethodParameter#getParameterAnnotations
called java.lang.Method#getParameterAnnotations on every invocation.
The latter ends up contending for a monitor inside (Sun) JDK code. This
is problematic when dealing with the high number of @RequestMapping
invocations that can occur in a Spring MVC @Controller.
This commit eliminates this contention by caching values returned by
java.lang.Method#getParameterAnnotations in a static ConcurrentMap.
Note that only Method parameter annotations are cached, while
Constructor parameter annotations are not. This is because the
issue of primary concern is, as mentioned above, @RequestMapping
methods. By nature, constructors are called much more infrequently, and
in most cases in a single-threaded fashion.
Issue: SPR-9298
InjectionMetadata and LifecycleMetadata can end up having mostly empty
instance variables. In such cases memory usage can be improved a little
bit.
This patch addresses this in two ways:
- Creating a LinkedHashSet of the "right" size, the default capacity
is 16 but the exact capacity needed is known in advance.
- If the argument is empty then use Collections#emptySet which is a
constant so no additional memory is used. Since it's immutable there
is no need for the Collections#synchronizedSet wrapper.
Issue: SPR-9264
Prior to this change, AABPP#determineRequiredStatus never checked the
return value of ReflectionUtils#findMethod when searching for a
'#required' attribute. This call returns null for annotations such as
@Inject, @Value and @Resource, and subsequently causes a
NullPointerException to be thrown when ReflectionUtils#invokeMethod is
called. The NPE is caught immediately and #determineRequiredStatus
returns defaulting to true, but this this approach is inefficient. It
is also problematic for users who have set breakpoints on NPE -- they
end up debugging into Spring internals, which is a false positive.
This commit checks the return value of of ReflectionUtils#findMethod,
and in the case of null, eagerly returns true. There is no change to
external behavior, simply a more efficient and debugging-friendly
implementation.
Existing test cases already cover this change, given that it is purely
a refactoring.
Issue: SPR-9316
AbstractTransactionalAnnotatedConfigClassTests is now annotated with
@DirtiesContext(classMode = ClassMode.AFTER_EACH_TEST_METHOD) so
that side-effects between tests are avoided.
Re-enabled TransactionalAnnotatedConfigClassWithAtConfigurationTests
and TransactionalAnnotatedConfigClassesWithoutAtConfigurationTests.
Also introduced a log4j FileAppender for tests that writes to
"build/spring-test.log".
Issue: SPR-9051
MappingJackson2JsonView and MappingJacksonJsonView now provide an
option that will set the Content-Length header of JSON responses.
Use of the option implies buffering of the response and it must be
enabled explicitly.
Issue: SPR-7866
This change makes it possible to provide a custom MessageCodesResolver
through the MVC Java config whether using @EnableWebMvc and extending
WebMVcConfigurerAdapter or sub-classing directly from
WebMvcConfigurationSupport.
Issue: SPR-9223
The claim: given an integration test class that is annotated with
@ContextConfiguration and declares a configuration class that is missing
an @Configuration annotation, if a transactional test method (i.e., one
annotated with @Transactional) changes the state of the database then
the
changes will not be rolled back as would be expected with the default
rollback semantics of the Spring TestContext Framework (TCF).
TransactionalAnnotatedConfigClassWithAtConfigurationTests is a concrete
implementation of AbstractTransactionalAnnotatedConfigClassTests that
uses
a true @Configuration class and thereby demonstrates the expected
behavior
of such transactional tests with automatic rollback.
TransactionalAnnotatedConfigClassesWithoutAtConfigurationTests is a
concrete implementation of
AbstractTransactionalAnnotatedConfigClassTests
that does NOT use a true @Configuration class but rather a 'lite mode'
configuration class (see the Javadoc for @Bean for details).
Using such a 'lite mode' configuration class results in the following:
- Its @Bean methods act as factory methods instead of singleton beans.
- The dataSource() method is invoked multiple times instead of once.
- The test instance and the TCF operate on different data sources.
- The transaction managed (and rolled back) by the TCF is not the
transaction that the application code or test instance uses.
Ultimately, the use of a 'lite mode' configuration class gives the false
appearance that there is a bug in the TCF (in that the transaction is
not
rolled back); however, the transaction managed by the TCF is in fact
rolled back.
In conclusion, these tests demonstrate both the intended behavior of the
TCF and the fact that using 'lite mode' configuration classes can lead
to
confusing results (both in tests and production code).
Issue: SPR-9051
SPR-7680 added QueryTimeoutException to Spring's DataAccessException
hierarchy, but did not integrate it into the
SQLExceptionSubclassTranslator; it was added mainly to accomodate users
defining their own custom exception translators.
However, it does make sense to translate any SQLTimeoutException to this
new QueryTimeoutException type, and this commit makes that change. It
does represent a slight backward-incompatibility, given that
QueryTimeoutException extends TransientDataAccessException, whereas
SQLExceptionSubclassTranslator previously returned the more specific
TransientDataAccessResourceException for any SQLTimeoutException.
It is expected that this incompatibily will be very low-impact, i.e. not
affecting many (if any) users. In any case, a major release (Spring 3.2)
is the right time to introduce such a change, and the migration path is
straightforward: any users depending on catching
TransientDataAccessResourceException in the case of query timeouts
should update those catch blocks to expect QueryTimeoutException
instead. Care should also be taken to ensure correctness of existing
catch blocks expecting TransientDataAccessException, as these blocks
will now catch QueryTimeoutException as well.
Issue: SPR-9376, SPR-7680
SPR-7591 introduced a java.nio.charset.Charset field within
HttpStatusCodeException. The former is non-serializable, thus by
extension the latter also became non-serializable.
Because the Charset field is only used for outputting the charset name
in HttpStatusCodeException#getResponseBodyAsString, it is reasonable to
store the value returned by Charset#name() instead of the actual Charset
object itself.
This commit refactors HttpStatusCodeException's responseCharset field to
be of type String instead of Charset and adds tests to prove that
HttpStatusCodeException objects are once again serializable as expected.
Issue: SPR-9273, SPR-7591
The new property can be used to ignore specific exceptions that may
otherwise be matched by the "exceptionMappings" property or resolved
through the defaultErrorView.
Issue: SPR-5193
It was claimed that when a {@code @ContextConfiguration} test class
references a config class missing an {@code @Configuration} annotation,
@Bean dependencies are wired successfully but the bean lifecycle is not
applied (no init methods are invoked, for example).
AnnotatedConfigClassesWithoutAtConfigurationTests refutes this claim by
demonstrating that @Bean methods in non-@Configuration classes are
properly handled as "annotated factory bean methods" and that lifecycle
callbacks in fact apply to such factory beans.
Issue: SPR-9051
When @ResponseStatus has a reason and servletResponse.sendError() is
called, the response is committed and should no longer be written to.
After this change, the ServletInvocableHandlerMethod will mark the
response fully handled and will ignore any non-null return values.
Issue: SPR-9159
Before this fix the q-value of media types in the Accept header were
ignored when using the new RequestMappingHandlerAdapter in combination
with @ResponseBody and HttpMessageConverters.
Issue: SPR-9160
The Spring TestContext Framework (TCF) currently builds against TestNG
5.10. Thus in order to ensure that the TCF builds against the latest
release of TestNG without issues and in order to investigate the
possibility of integrating with newer TestNG features, we are upgrading to
version 6.5.2.
Note, however, that the Gradle build currently does not execute any TestNG
tests; this will be addressed in SPR-9398.
Issue: SPR-8221
Spring currently builds against JUnit 4.9; however, in order to ensure
that the Spring TestContext Framework builds and runs against JUnit 4.10
without issues and in order to investigate the possibility of integrating
with newer JUnit features, we are upgrading to JUnit 4.10.
Issue: SPR-9277
The MappingJacksonHttpMessageConverter now catches all IOException
types raised while reading JSON and translates them into
HttpMessageNotReadableException.
Issue: SPR-9238
Previously RequestMappingHandlerMapping detected @RequestMapping
methods through an initApplicationContext() hook. However, the
HandlerMapping may not have been fully set up with all its
dependencies at that point including settings like useSuffixPattern
and others.
This change moves the detection @RequestMapping methods to an
InitializingBean.afterPropertiesSet() hook.
Issue: SPR-9371
This was supported in DefaultAnnotationHandlerMapping but not in the
RequestMappingHandlerMapping. The specific scenario where this matters
is a controller decorated with a JDK proxy. In this scenario the
HandlerMapping looks at interfaces only to decide if the bean is a
controller. The @Controller annotation is better left (and required)
on the class.
Issue: SPR-9374
The ErrorsMethodArgumentResolver expects the preceding @ModelAttribute
in the controller method signature to be the last one added in the
model -- an assumption that can break if a model attribute is added
earlier (e.g. through a @ModelAttribute method) and more attributes
are added as well. This fix ensures when an @ModelAttribute is resolved
as a controller method argument it has the highest index in the model.
Issue: SPR-9378
Two tests in MockServletContextTests were disabled with @Ignore with the
comment "fails to work under ant after move from .testsuite -> .test";
however, this no longer appears to apply with the Gradle build. Thus
these tests have been re-enabled.
The JavaDoc in OpMultiply contained special characters that caused
problems when building with Java 7 on Mac OS X. The section symbol has
been replaced with the word "Section". Also improved class-level and
method-level JavaDoc in general.
Jackson serialization supports pretty printing. Usually it's enabled
by invoking ObjectMapper.configure(..), which is not convenient for
apps with XML configuration. The Jackson HttpMessageConverter and View
now both have a prettyPrint property.
A second more serious issue is documented here:
https://github.com/FasterXML/jackson-databind/issues/12
The workaround discussed at the above link has been implemented.
Issue: SPR-7201
Jackson 2 uses completely new package names and new maven artifact ids.
This change adds Jackson 2 as an optional dependency and also provides
MappingJackson2HttpMessageConverter and MappingJackson2JsonView for use
with the new version.
The MVC namespace and the MVC Java config detect and use
MappingJackson2HttpMessageConverter if Jackson 2 is present.
Otherwise if Jackson 1.x is present,
then MappingJacksonHttpMessageConverter is used.
Issue: SPR-9302
OSIV deferred close mode is not supported with async requests and is
unlikely to be what's the desired. This change adds an exception with
a message stating this.
Issue: SPR-8517
This change updates Open-Session-in-View filters and interceptors for
use in async requests mainly ensuring the open Hibernate session is
unbound from the main request processing thread and bound to the to
async thread.
Issue: SPR-8517
The fromUri method of UriComponentsBuilder used uri.getXxx() methods,
which decode the URI parts causing URI parsing issues. The same method
now uses uri.getRawXxx().
Issue: SPR-9317
Prior to this change, request-scoped components having
@Resource-injected dependencies caused a memory leak in
DefaultListableBeanFactory#dependenciesForBeanMap.
Consider the following example:
@Component
@Scope(value="request", proxyMode=ScopedProxyMode.TARGET_CLASS)
public class MyComponent {
@Resource
private HttpServletRequest request;
// ...
}
The bean name for "MyComponent" will end up being
'scopedTarget.myComponent', which will become a key in
the #dependenciesForBeanMap structure.
On the first request, the injected HttpServletRequest bean will be a
proxy and will internally have a bean name of the form
"$Proxy10@1a3a2a52". This name will be added to the Set value associated
with the 'scopedTarget.myComponent' entry in #dependenciesForBeanMap.
On the second request, the process will repeat, but the injected
HttpServletRequest will be a different proxy instance, thus having a
different identity hex string, e.g. "$Proxy10@5eba06ff". This name will
also be added to the Set value associated with the
'scopedTarget.myComponent' entry in #dependenciesForBeanMap, and this
is the source of the leak: a new entry is added to the set on each
request but should be added only once.
This commit fixes the leak by introducing caching to
CommonAnnotationBeanPostProcessor#ResourceElement similar to that already
present in AutowiredAnnotationBeanPostProcessor#AutowiredFieldElement
and #AutowiredMethodElement. Essentially, each ResourceElement instance
now tracks whether it has been created, caches the ultimate value to be
injected and returns it eagerly if necessary. Besides solving the memory
leak, this has the side effect of avoiding unnecessary proxy creation.
This fix also explains clearly why injection into request-scoped
components using @Autowired never suffered this memory leak: because the
correct caching was already in place. Because @Resource is considerably
less-frequently used than @Autowired, and given that this particular
injection arrangement is relatively infrequent, it becomes
understandable how this bug has been present without being reported
since the introduction of @Resource support in Spring 2.5: developers
were unlikely to encounter it in the first place; and if they did, the
leak was minor enough (adding strings to a Set), that it could
potentially go unnoticed indefinitely depending on request volumes and
available memory.
Issue: SPR-9176
Prior to this commit, SpEL's OpPlus ('+' operator) would convert its
left and right operands to String directly via #toString calls.
This change ensures that operand values are delegated to any registered
converters, allowing for customization of the stringified output.
Note that the OpPlus constructor now throws IllegalArgumentException if
zero operands are supplied.
Issue: SPR-8308
Before this change there were numerous javadoc warnings being reported
while building Spring framework API.
This commit resolves most of the javadoc warnings, reducing the total
number from 265 to 103.
Issue: SPR-9113
Before this change javadoc in two classes had non-UTF-8 encoded
characters. This caused building Spring API to fail in Java 1.7.
Commit fixes this by replacing wrongly encoded characters with their
UTF-8 equivalents.
Issue: SPR-9097
When a controller returns a DeferredResult, the underlying async
request will eventually time out. Until now the default behavior was
to send a 503 (SERVICE_UNAVAILABLE). However, this is not desirable
in all cases. For example if waiting on an event, a timeout simply
means there is no new information to send.
To handle those cases a DeferredResult now accespts a timeout result
Object in its constructor. If the timeout occurs before the
DeferredResult is set, the timeout result provided to the constructor
is used instead.
Issue: SPR-8617
* Clarify semantics and behavior of AsyncWebRequest methods in most cases
making a best effort and not raising an exception if async processing
has completed for example due to a timeout. The startAsync() method is
still protected with various checks and will raise ISE under a number
of conditions.
* Return 503 (service unavailable) when requests time out.
* Logging improvements.
Issue: SPR-8517
From a programming model perspective, @RequestMapping methods now
support two new return value types:
* java.util.concurrent.Callable - used by Spring MVC to obtain the
return value asynchronously in a separate thread managed transparently
by Spring MVC on behalf of the application.
* org.springframework.web.context.request.async.DeferredResult - used
by the application to produce the return value asynchronously in a
separate thread of its own choosing.
The high-level idea is that whatever value a controller normally
returns, it can now provide it asynchronously, through a Callable or
through a DeferredResult, with all remaining processing --
@ResponseBody, view resolution, etc, working just the same but
completed outside the main request thread.
From an SPI perspective, there are several new types:
* AsyncExecutionChain - the central class for managing async request
processing through a sequence of Callable instances each representing
work required to complete request processing asynchronously.
* AsyncWebRequest - provides methods for starting, completing, and
configuring async request processing.
* StandardServletAsyncWebRequest - Servlet 3 based implementation.
* AsyncExecutionChainRunnable - the Runnable used for async request
execution.
All spring-web and spring-webmvc Filter implementations have been
updated to participate in async request execution.
The open-session-in-view Filter and interceptors implementations in
spring-orm will be updated in a separate pull request.
Issue: SPR-8517
Previously depending on 1.5.10 in certain locations, which caused
NoClassDefFoundErrors in EhCacheCacheTests and other tests due to
mismatches between slf4j -api and -log4j12 versions.
With the exception of one transitive dependency via Hibernate 3.3.1.GA,
all slf4j dependencies are now pegged at 1.6.1 (and all tests pass).
Before this change, IDE settings generated via import-into-eclipse.sh
created a classpath dependency on slf4j-api version 1.6.1 and
slf4j-log4j12 version 1.5.10. As a result running tests inside the IDE
resulted in a NoSuchMethodException.
build.gradle sets the variable slf4jLog4jVersion to '1.5.10'. However,
the hibernate-validator dependency in spring-context pulls in
slf4j-api version 1.6.1. The change ensures the version specified in
the build script variable is used consistently. Whether it should be
1.5.10 or 1.6.1 is a separate concern.
- Spring remains compatible against AJ version 1.6.8, but is now
compiling and testing against 1.6.12
- Encountered what appears to be an AJ bug introduced in 1.6.10: an
assertion in org.aspectj.weaver.UnresolvedType causes a false
negative failure when encountering org.springframework.io.Resource
arrays, e.g. "[org.springframework.io.Resource@xxx". This problem
has been reported to the AJ team and in the meantime, the recommended
workaround is to disable assertions either completely, or at least
selectively with
-disableassertions:org.aspectj.weaver.UnresolvedType
Issue: SPR-7989, SPR-9272
- Fix deprecation warnings about dynamic properties; favor use of
"extra properties extensions" per [1]
- Certain such deprecations are still issued due to violations within
the docbook-reference plugin. These will be fixed in an upcoming
revision of the plugin, at which point spring-framework will upgrade
to depend on it and these warnings will be eliminated
[1] http://gradle.org/docs/current/dsl/org.gradle.api.plugins.ExtraPropertiesExtension.html
Issue: SPR-9327
The new @MVC support classes select a HandlerMethodArgumentResolver
and a HandlerMethodReturnValueHandler statically, i.e. based on
the signature of the method, which means that a controller method
can't declare a more general return type like Object but actually
return a more specific one, e.g. String vs RedirectView, and
expect the right handler to be used.
The fix ensures that a HandlerMethodReturnValueHandler is selected
based on the actual return value type, which is something that was
supported with the old @MVC support classes. One consequence
of the change is the selected HandlerMethodReturnValueHandler can
no longer be cached but that matches the behavior of the old
@MVC support classes.
Issues: SPR-9218
Previously 'Content-Disposition' was passed to Part.getHeader(String).
However the Javadoc for that method specifies the header should be
case insensitive. Note that the JavaDoc in tomcat-servlet-api doesn't
mention this. It can only be found in the official api JavaDoc:
http://download.oracle.com/otndocs/jcp/servlet-3.0-fr-oth-JSpec/
Issue: SPR-9149
Invalid Content-Type or Accept header values previously resulted in the
IllegalArgumentException getting propagated. After this change such
errors are detected and generally treated as a "no match", which
may for example result in a 406 in the case of the Accept header.
Issue: SPR-9148
A custom RequestCondition which can be provided by overriding methods
in RequestMappingHandlerMapping worked only for conditions that match
and did not return null (as it should have) for conditions that don't
match.
Issues: SPR-9134
Copy spring-*-3.1.xsd => spring-*-3.2.xsd; this commit introduces no
substantive changes, but rather prepares for them by creating a clean
baseline. All internal references to 3.1 schemas (e.g. spring-tool) have
also been updated.
Before this change JibxMarshaller did not use the configured encoding
when unmarshalling XML. This caused issues when content being
unmarshalled was not encoded using the default encoding.
This commit fixes the issue by passing configured encoding to JiBX so
it gets used when unmarshalling instead of the default encoding.
Issue: SPR-7865
Use the preferred SessionFactoryImplementor#getDialect call as
opposed to the previous Dialect#getDialect approach which required
explicitly setting the 'hibernate.dialect' property.
Issue: SPR-7396
This change fixes a mistake made during an earlier sync with the 3.1.x
branch in which the new QueryTimeoutException class was accidentally
placed in spring-transaction instead of spring-tx.
Issue: SPR-7680
Before this change if FreeMarker Spring form macro was bound to a path
which contains square brackets, those brackets would also appear in id
of generated tag, making the id invalid.
As of this fix all FreeMarker Spring form macros generate tag with id
that does not contain square brackets.
Issue: SPR-8732
Before this fix MultipartResolver javadoc mentioned that there is only
one concrete implementation included in Spring. This was true as of
Spring 2.5 but Spring 3.1 added another one, Servlet 3.0 Part API based
implementation.
This fix changes MultipartResolver javadoc so that the other one,
StandardServletMultipartResolver implementation, gets also listed.
Changed javadoc mentions also as of which version does Spring bundle
two MultipartResolver implementations.
Issue: SPR-5984
Before this change bean scopes chapter in Spring reference documentation
had a note which mentioned that creating a scoped proxy for singleton-
or prototype-scoped beans will throw BeanCreationException.
This is no longer the case and this change removes the mentioned note.
Issue: SPR-7940
Prior to this commit, MutablePropertySources#get(String) would throw
IndexArrayOutOfBoundsException if the named property source does not
actually exist. This is a violation of the PropertySource#get contract
as described in its Javadoc.
The implementation now correctly checks for the existence of the named
property source, returning null if non-existent and otherwise returning
the associated PropertySource.
Other changes
- Rename PropertySourcesTests => MutablePropertySourcesTests
- Polish MutablePropertySourcesTests for style, formatting
- Refactor MutablePropertySources for consistency
Issue: SPR-9179
JDK7 changed its reflections API in order to resolve
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5041784
In short, JDK 5 and 6 (wrongly) return GenericArrayTypes in certain
reflection scenarios, whereas JDK 7 changed this to return a normal
array type. For Jaxb2Marshaller, this meant that marshaling byte arrays
was not supported under JDK 7.
This change fixes that, so that Jaxb2Marhsaller supports marshalling
byte arrays again (under JDK 5, 6 or 7).
Due to changes made in commit 2fa87a71 for SPR-9118,
AbstractResource#contentLength would fall into an infinite loop unless
the method were overridden by a subclass (which it is in the majority of
use cases).
This commit:
- fixes the infinite recursion by refactoring to a while loop
- asserts that the value returned from #getInputStream is not null in
order to avoid NullPointerException
- tests both of the above
- adds Javadoc to the Resource interface to clearly document that the
contract for any implementation is that #getInputStream must not
return null
Issue: SPR-9161
- Rename customized .wrapper to default gradle/wrapper directory for
out of the box compatibility with STS Gradle tooling
- Add .settings/gradle directory to capture defaults when using STS
Gradle tooling to import projects
Prior to this change, before a bean is created by EhCacheFactoryBean,
its #getObjectType would return only an Ehcache interface. This caused
unwanted wiring issues as described in the related JIRA issue.
This fix makes use of EhCacheFactoryBean's configuration to determine
the specific Ehcache object type even before it's created, such that
the container is provided with as much information as possible when
resolving dependencies. Nevertheless, users are advised to code to
the Ehcache interface.
Issue: SPR-7843
ORA-00054 is already mapped to CannotAcquireLockException and is
described as
"resource busy and acquire with NOWAIT specified"
As pointed out in the associated JIRA issue, ORA-30006 is quite similar
being described as
"resource busy; acquire with WAIT timeout expired"
This commit maps ORA-30006 to CannotAcquireLockException as well.
Issue: SPR-9141
Changes in commit 41ade68b50 introduced
a regression causing all but the first location in the
@PropertySource#value array to be ignored during ${...} placeholder
resolution. This change ensures that all locations are processed and
replaced as expected.
Issue: SPR-9133, SPR-9127
* 3.1.x:
Warn re Environment construction and instance vars
Disallow empty @PropertySource(value = {})
Fix @PropertySource bug with multiple values
final preparations for 3.1.1 release
added "receive-timeout" attribute to "jms:listener-container" element
* 3.1.x:
Demonstrate use of @Configuration as meta-annotation
Prune dead code from JmsTransactionManager#doBegin
Apply @Configuration BeanNameGenerator consistently
Improve @Configuration bean name discovery
Fix infinite recursion bug in nested @Configuration
Polish static imports
Minor fix in ServletResponseMethodArgumentResolver
extracted ResourceUtils.useCachesIfNecessary(URLConnection) method (SP
prepared for 3.1.1 release
CustomSQLExceptionTranslatorRegistry/Registrar etc
revised CustomSQLExceptionTranslatorRegistry/Registrar method naming
use custom InputStream traversal instead of a full byte array (SPR-911
PathMatchingResourcePatternResolver preserves caching for JNLP jar con
Resource "contentLength()" implementations work with OSGi bundle resou
fixed MethodInvokingJobDetailFactoryBean for compatibility with Quartz
fixed MethodInvokingJobDetailFactoryBean for compatibility with Quartz
* 3.1.x: (61 commits)
Compensate for changes in JDK 7 Introspector
Avoid 'type mismatch' errors in ExtendedBeanInfo
Polish ExtendedBeanInfo and tests
Infer AnnotationAttributes method return types
Minor fix in MVC reference doc chapter
Hibernate 4.1 etc
TypeDescriptor equals implementation accepts annotations in any order
"setBasenames" uses varargs now (for programmatic setup; SPR-9106)
@ActiveProfiles mechanism works with @ImportResource as well (SPR-8992
polishing
clarified Resource's "getFilename" method to consistently return null
substituteNamedParameters detects and unwraps SqlParameterValue object
Replace spaces with tabs
Consider security in ClassUtils#getMostSpecificMethod
Adding null check for username being null.
Improvements for registering custom SQL exception translators in app c
SPR-7680 Adding QueryTimeoutException to the DataAccessException hiera
Minor polish in WebMvcConfigurationSupport
Detect overridden boolean getters in ExtendedBeanInfo
Polish ExtendedBeanInfoTests
...
The build script should work against http anyway; use of https here was
an oversight. Changing it now is in response to the following build
failure experienced by a user on his initial attempt to build from
source (with --info output):
09:02:09.437 [ERROR] [org.gradle.BuildExceptionReporter] Caused
by: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
...
Cause: Could not GET
https://repo.springsource.org/plugins-snapshot/org/springframework/
build/gradle/docbook-reference-plugin/0.1.2-SNAPSHOT/maven-metadata.xml
The actual cause is unknown at this time, but worth noting that upon
switching the url to http, the following log message was issued:
Forcing close on abandoned resource: Http GET Resource:
http://repo.springsource.org/plugins-snapshot/org/springframework/
build/gradle/docbook-reference-plugin/0.1.2-SNAPSHOT/maven-metadata.xml
Previously, the build script was configured to add ajbuilder to the set
of Eclipse/STS build commands, meaning that both javabuilder and
ajbuilder would be present for spring-aspects. This causes unpredictable
behavior, as these two builders compete with each other. As ajbuilder is
a functional superset of javabuilder, this commit ensures that only the
former is present for spring-aspects' .project file.
Also removed warning language in import-into-eclipse.sh about
spring-aspects failing after adding Git support, as this intermittent
problem was almost certainly an artifact of the situation described
above.
User may already have run `gradle build` successfully. This change
ensures that we do not unnecessarily remove these output directories
in order to avoid forcing the user to rebuild.
This is the first merge from 3.1.x => master after the Gradle build
system migration. Notice how files changed under the 3.1.x directory
structure (org.springframework.*) merge seamlessly into the new
directory structure (spring-*).
Certain files had changed under 3.1.x that have since been deleted with
the Gradle build migration, e.g. all pom.xml files had <license>
sections added. These files showed up as a conflict during the merge,
but the resolution is to simply re-remove them and commit as they are
no longer relevant under 3.2.x / master.
Also noteworthy is the .gitignore file. It has been updated under 3.1.x
to ignore files and directories specific to the new Gradle-based
structure. However, this causes conflicts when trying to merge against
master, given that master should *not* ignore this directories. The
resolution in this situation is to simply force the 'master' version of
the file, i.e. when prompted for merge resolution:
anakata:~/Work/spring-framework/spring-framework[master|MERGING]
$ git status -sb
## master...springsource/master [ahead 24]
UU .gitignore
anakata:~/Work/spring-framework/spring-framework[master|MERGING]
$ git checkout master .gitignore
anakata:~/Work/spring-framework/spring-framework[master|MERGING]
$ git commit
It is helpful in situations like this one to enable git's "rerere"
feature beforehand, which records and remembers resolution strategies,
avoiding the need to repeat them in future merges:
$ git config --global rerere.enabled 1
See:
http://progit.org/2010/03/08/rerere.htmlhttp://gitfu.wordpress.com/2008/04/20/git-rerere-rereremember-what-you-did-last-time
Conflicts:
.gitignore
.springframework.*/pom.xml
This merge migrates the Spring Framework 3.2.x build system to Gradle.
Major changes
- Remove Ant-based spring-build and related resources
- Replace with Gradle-based build
- Remove (and .gitignore) all IDE metadata files
- Remove hand-maintained Maven poms in favor of generation by Gradle
- Move integration-tests subproject to root src/test dir
- Move spring-framework-reference subproject to root src/reference dir
- Rename org.springframework.* subprojects => spring-*
See individual messages for the commits included in this merge for
details on each of these changes.
Documentation
- https://github.com/SpringSource/spring-framework#building_from_source
- https://github.com/SpringSource/spring-framework/wiki
see 'Build and release FAQ' and 'SpringSource repository FAQ'
Issue: SPR-8116
- Update building from source section with Gradle instructions
- Add import-into-eclipse.sh interactive helper script
- Add import-into-idea.md with steps and known issues
Note that use of STS Gradle tooling was attempted, but several issues
remain before it can handle the spring-framework build. In the meantime
the instructions laid out in import-into-eclipse provide an error-free
import.
Eclipse .project, .classpath, and .settings metadata have already been
removed. Now removing Eclipse .psf and formatter XML files from the root
project as well as removing all manually-maintained IDEA .iml and .ipr
files.
This is in favor of using Gradle's own 'eclipse' and 'idea' tasks that
generate this kind of metadata on the fly.
.gitignore has been updated to ignore these files going forward. In any
case, they should not be checked into the source tree! The README.md
file will be updated to explain how to generate these files using gradle
and how to import the projects into your IDE of choice.
Each of these tests began failing during the Gradle build porting
process. None seem severe, many are likely due to classpath issues.
In the case of TestNG support, this needs to be added to the Gradle
build in order to execute these tests. See SPR-8116.txt
- Fix compileTestJava issue in which test classes were not being
compiled or run
- Use built-in eclipse.project DSL instead of withXml closure
to add AspectJ nature and builder
- Rename {aspectJ=>aspects}.gradle and format source
e.g.:
Implementation-Title: spring-core
Implementation-Version: 3.2.0.BUILD-SNAPSHOT
Setting these values is good as a general practice, but required in
order to support the functionality in spring-core's SpringVersion class.
This renaming more intuitively expresses the relationship between
subprojects and the JAR artifacts they produce.
Tracking history across these renames is possible, but it requires
use of the --follow flag to `git log`, for example
$ git log spring-aop/src/main/java/org/springframework/aop/Advisor.java
will show history up until the renaming event, where
$ git log --follow spring-aop/src/main/java/org/springframework/aop/Advisor.java
will show history for all changes to the file, before and after the
renaming.
See http://chrisbeams.com/git-diff-across-renamed-directories
Understanding Gradle pom generation
-------------------------------------------
All spring-* subprojects have had Gradle's 'maven' plugin applied to
them. This means that one can run `gradle install`, and POMs will be
generated according to the metadata in the build.gradle file.
The 'customizePom' routine added by this commit hooks into this
generation process in order to add elements to the pom required for
entry into Maven Central via oss.sonatype.org[1].
This pom generation happens on-the-fly during `gradle install` and
the generated poms exist only in your local .m2 cache. Therefore,
you will not see the poms on the source tree after this command.
Handling optional and provided dependencies
-------------------------------------------
Note particularly the handling of 'optional' and 'provided'
dependencies. Gradle does not have a first class notion for these
concepts, nor are they significant to the actual Gradle build process,
but they are important when publishing POMs for consumption via Maven
Central and other Maven-compatible repositories.
<optional>true</optional> indicates that a dependency need not be
downloaded when resolving artifacts. e.g. spring-context has an
compile-time dependency on cglib, but when a Spring user resolves
spring-context from Maven Central, cglib should *not* automatically
be downloaded at the same time. This is because the core functionality
within spring-context can operate just fine without cglib on the
classpath; it is only if the user chooses explicitly to use certain
functionality, e.g. @Configuration classes, which do require cglib,
that the user must declare an explicit dependency in their own build
script on cglib.
Marking these kinds of dependencies as 'optional' provides a kind of
built in 'documentation' about which version of cglib the user should
declare if in fact he wishes to.
Spring has a great many compile-time dependencies, but in fact very
few mandatory runtime dependencies. Therefore, *most* of Spring's
dependencies are optional.
<scope>provided</scope> is similar to 'optional', in that dependencies
so marked should not be automatically downloaded during dependency
resolution, but indicates rather that they are expected to have been
provided by the user application runtime environment. For example, the
Servlet API is in fact a required runtime dependency for spring-webmvc,
but it is expected that it will be available via the user's servlet
container classpath. Again, it serves here as a kind of 'documentation'
that spring-webmvc does in fact expect the servlet api to be available,
and furthermore which (minimum) version.
This commit adds two closures named 'optional' and 'provided' as well as
two arrays (optionalDeps, providedDeps) for tracking which dependencies
are optional or provided. An optional dependency is declared as follows:
compile("group:artifact:version", optional)
Here, the optional closure accepts the dependency argument implicitly,
and appends it to the 'optionalDeps' array. Then, during pom generation
(again, the customizePom routine), these arrays are interrogated, and
pom <dependency> elements are updated with <optional>true</optional> or
<scope>provided</scope> as appropriate. Thanks to the Spock framework
for inspiration on this approach[2].
[1] http://bit.ly/wauOqP (Sonatype's central sync requirements)
[2] https://github.com/spockframework/spock/blob/groovy-1.7/gradle/publishMaven.gradle#L63
Only a select few EBR dependencies now remain, because these
dependencies cannot be found elsewhere e.g. atinject-tck, or in the case
of Hibernate 3.3.1.GA, to avoid Gradle classpath confusion with
Hibernate 4.0.x (because they have different artifactIds).
Future efforts will be made to fully eliminate these dependencies in
order to ensure we're decoupled completely from EBR.
Important note: these remaining EBR dependencies do not constitute a
problem when publishing artifacts into Maven Central via
oss.sonatype.org, because they are each 'optional' dependencies. It
appears that OSO's restriction around transitive dependencies being
'self-contained' within Maven Central only applies to mandatory
dependencies (which is a good thing for cases just such as this).
Add explicit /ebr-maven-external entry to repositories, as EBR
dependencies are not available via /libs-release.
- Apply custom-built Gradle 'bundlor' plugin
This plugin wraps the existing bundlor ant task. Sources available
at https://github.com/SpringSource/gradle-plugins.
- Use existing template.mf files
The bundlor plugin allows for 'inlining' bundlor templates directly
within build.gradle using the 'importTemplate' property, but opting
for now to keep the template.mf files separate.
- Exclude spring-aspects from bundlor processing
It appears that the bundlor plugin somehow interferes with iajc
compilation of aspects, resulting in compiler errors. Bundlor
has been disabled for this project for the time being.
- Fail the build on any bundlor warning
The gradle bundlor plugin defaults to failing the build if there are
any warnings when processing template.mf files. This helps to ensure
that template.mf files don't drift too far from actual dependency
declarations. This behavior can be modified by setting
bundlor {
failOnWarnings = false
}
in the build script.
- Generate castor test classes with genCastor task
- Generate xmlbeans test classes with genXmlbeans task
- Generate JAXB2 test classes with genJaxb task
- Generate JiBX bindings by extending existing compileTestJava task
Test classes are written into their own dedicated output folders and
tied into the spring-oxm classpath using the files(...).builtBy(...)
directive.
Incremental build works as expected across all of these customizations.
`gradle eclipse` and `gradle idea` generate correct .project / .iml
metadata respectively, i.e., these special cases do not cause a problem
in the IDE (as they used to prior to the move to Gradle).
Each spring-* subproject now has sourcesJar and javadocJar tasks
- Ignore subproject overview.html files for now (not all have one)
- Ensure @author attribution occurs
- Javadoc 'header' is project description
spring-asm is a special case
- source jar is created, but empty (to comply with entry rules for
Maven Central)
- add package-info.java explaining the nature of spring-asm
this is nice, because it shows up in the public API docs now.
- add SpringAsmInfo in the org.springframework.asm package as a
placeholder allowing the generation of javadocs (see link to bug)
- add explicit 'repackageAsm' Gradle task allowing for easy testing
and merging of jar containing bundlor manifest as well as jar
containing repackaged ASM classes.
- Add 'api' gradle task to generate project-wide API Javadoc
results in <root>/build/api
- Add docsZip task including api and reference documentation
suitable for publication to
http://static.springframework.org/docs/spring-framework
- Add schemaZip task including all spring-* XSD files
suitable for publication to http://static.springframework.org/schema
- Add distZip task to include all libs, docs and schema
- filter src/dist/*.txt for ${copyright} and ${version}
- copy legal (notice, license) dynamically into individual jar files
- copy legal and readme files into root of distribution zip
- Refactor location of 'wrapper' task
Each of the zip tasks (docsZip, schemaZip, distZip) have been added to
the 'archives' configuration, meaning that (a) they will be built
automatically with `gradle build` and (b) will be published
automatically to artifactory when using the Artifactory Gradle plugin
and/or Artifactory Bamboo integration.
Prior to this change, license.txt and notice.txt files were duplicated
across every subproject in their respective src/main/resources/META-INF
directories.
This commit centralizes these files under the root project at src/dist,
along with the changelog and readme files. The definition of the 'jar'
task has been been extended to include the license and notice files in
module jars as they are created.
The directory is named src/dist because these files are all related to
distribution - the readme is different than the one you see at the root
of the source tree - the intended audience is for users who download
the spring-framework distribution zip. A task to create that
distribution zip will be added in subsequent commits.
Problems
- Eliminate — in favor of —
— was causing 'no such entity' errors during docbook
processing; — produces the equivalent output.
- Fix column issues in appendices
column counts were set to 3, when they are in fact 4. This passed
under DocBook 4 and Spring Build for unknown reasons, but caused a
hard stop under DocBook 5 and the docbook-reference-plugin.
- Add jdbc callout section in docbook 5-friendly style
use <co/> tags as advertised in DocBook documentation.
- Set correct widths for PDF ref doc images
images were rendering larger than the PDF page; just set all to
width=400 and everything looks good.
Polish
- Update reference doc copyright to 2012
- Remove "work-in-progress" language from ref docs
- Update maven URLs to repo.springsource.org
- Update javadoc urls from 3.0.x/javadoc-api => current/api
- Replace hardcoded "3.1" with ${version} in ref doc
It was determined (through painful trial and error) that after the
upgrade to DocBook 5 and the gradle-docbook-reference plugin, that
<emphasis> elements embedded within <programlisting> elements causes
NullPointerExceptions during processing.
This change eliminates these <emphasis> elements to work around the
problem. This means a slight degradation in presentation for the
affected areas of the reference documentation. After some research,
it is not clear what other workarounds may be possible that leave
the text actually emphasized.
The docbook-gradle-plugin has been custom-developed specifically to
handle Spring projects. It is highly opinionated, and not terribly
configurable in its current form. Sources and documentation are
available via the 'gradle-plugins' github repository at
https://github.com/cbeams/gradle-plugins
Note that this repository may soon move locations to the SpringSource
GitHub organization, in which case the url will be
https://github.com/SpringSource/gradle-plugins
In any case, the build plans for these plugins can be found at
https://build.springsource.org/browse/GRADLEPLUGINS
This change eliminates the spring-framework-reference subproject, moving
these sources into the root project's own src directory.
This makes sense because the reference docs span all submodules, and
also because api Javadoc is created at the root project level as well.
This means that both api and reference documentation output will now
reside in the root project's 'build' directory. This is more consistent
and easy to discover.
This commit eliminates the 'integration-tests' subproject in favor of
managing these sources under the root project's own 'src' directory.
This helps to avoid special-case handling for integration-tests in the
Gradle build, e.g. avoiding publication of jars to Artifactory /
Maven Central.
It is also semantically more correct. This is not a Spring Framework
subproject so much as it is a collection of integration tests that
span functionality across many subprojects. In this way, it makes
sense to place them directly under the root project.
Issue: SPR-8116
- Use recent Gradle 1.0-milestone-8 snapshot
- Add initial cut of build.gradle able to compile/test all modules
- Update .gitignore
- Generate Gradle wrapper scripts
- Remove all Eclipse metadata files
- Temporarily @Ignore tests that do not pass under Gradle
Reconciled all 3.1.1 dev against 3.1.x and master (3.2.x) branches.
From this point forward, all 3.1.1 dev should happen directly against
3.1.x, and we will periodically merge those changes into master.
Note that when these merges take place, there will be a conflict
among any files containing version numbers, such as build.properties
and pom files. Use `git rerere` to record the conflict resolution
strategy for future merges, avoiding redundant work.
$ git config --global rerere.enabled 1
$ git checkout master
$ git merge 3.1.x # conflicts
$ git checkout master # take master version of all affected files
$ git commit # conflict resolution strategy is remembered
See http://progit.org/2010/03/08/rerere.html
Conflicts:
build.properties
org.springframework.aop/pom.xml
org.springframework.asm/pom.xml
org.springframework.aspects/pom.xml
org.springframework.beans/pom.xml
org.springframework.context.support/pom.xml
org.springframework.context/pom.xml
org.springframework.core/pom.xml
org.springframework.expression/pom.xml
org.springframework.instrument.tomcat/pom.xml
org.springframework.instrument/pom.xml
org.springframework.integration-tests/pom.xml
org.springframework.jdbc/pom.xml
org.springframework.jms/pom.xml
org.springframework.orm/pom.xml
org.springframework.oxm/pom.xml
org.springframework.spring-library/pom.xml
org.springframework.spring-parent/pom.xml
org.springframework.test/pom.xml
org.springframework.transaction/pom.xml
org.springframework.web.portlet/pom.xml
org.springframework.web.servlet/pom.xml
org.springframework.web.struts/pom.xml
org.springframework.web/pom.xml
Prior to this change, roughly 5% (~300 out of 6000+) of files under the
source tree had CRLF line endings as opposed to the majority which have
LF endings.
This change normalizes these files to LF for consistency going forward.
Command used:
$ git ls-files | xargs file | grep CRLF | cut -d":" -f1 | xargs dos2unix
Issue: SPR-5608
spring-build was previously included via an svn:external. Adding
directly to the source tree under Git to avoid the need for a git
submodule.
In order to build from any earlier commit, it is recommended to
export spring-build or symlink an existing copy into the root
of the spring-framework project and then build normally.
$ svn export https://src.springsource.org/svn/spring-build/tags/project-build-2.5.2 spring-build
2011-12-15 02:40:18 +01:00
7717 changed files with 300798 additions and 276201 deletions
// Replace classpath entries with project dependencies (GRADLE-1116)
eclipse.classpath.file.whenMerged{classpath->
defregexp=/.*?\/([^\/]+)\/build\/[^\/]+\/(?:main|test)/// only match those that end in main or test (avoids removing necessary entries like build/classes/jaxb)
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Spring Buildmaster
