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
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
Fix serialization warnings by applying @SuppressWarnings("serial")
when appropriate.
In certain cases and for unknown reasons, a correctly-placed
@SuppressWarnings("serial") annotation will fix the warning at the
javac level (i.e. the Gradle command-line), but will produce an
"unnecessary @SuppressWarnings" warning within Eclipse. In these
cases, a private static final serialVersionUID field has been added
with the default value of 1L.
In particular, avoiding synchronized Sets and Maps wherever possible (preferring a ConcurrentHashMap even instead of a synchronized Set) and specifying appropriate ConcurrentHashMap initial capacities (even if we end up choosing 16).
- Support external Javadoc links using Gradle's javadoc.options.links
- Fix all other Javadoc warnings, such as typos, references to
non-existent (or no longer existent) types and members, etc,
including changes related to the Quartz 2.0 upgrade (SPR-8275) and
adding the HTTP PATCH method (SPR-7985).
- Suppress all output for project-level `javadoc` tasks in order to
hide false-negative warnings about cross-module @see and @link
references (e.g. spring-core having a @see reference to spring-web).
Use the `--info` (-i) flag to gradle at any time to see project-level
javadoc warnings without running the entire `api` task. e.g.
`gradle :spring-core:javadoc -i`
- Favor root project level `api` task for detection of legitimate
Javadoc warnings. There are now zero Javadoc warnings across the
entirety of spring-framework. Goal: keep it that way.
- Remove all @link and @see references to types and members that exist
only in Servlet <= 2.5 and Hibernate <= 4.0, favoring 3.0+ and 4.0+
respectively. This is necessary because only one version of each of
these dependencies can be present on the global `api` javadoc task's
classpath. To that end, the `api` task classpath has now been
customized to ensure that the Servlet 3 API and Hibernate Core 4 jars
have precedence.
- SPR-8896 replaced our dependency on aspectjrt with a dependency on
aspectjweaver, which is fine from a POM point of view, but causes
a spurious warning to be emitted from the ant iajc task that it
"cannot find aspectjrt on the classpath" - even though aspectjweaver
is perfectly sufficient. In the name of keeping the console quiet, a
new `rt` configuration has been added, and aspectjrt added as a
dependency to it. In turn, configurations.rt.asPath is appended to
the iajc classpath during both compileJava and compileTestJava for
spring-aspects.
Issue: SPR-10078, SPR-8275, SPR-7985, SPR-8896
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
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
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
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
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
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
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
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
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
