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
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
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
* 3.2.x:
Fix ClassCastException when setting media types
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
Fix null parameterName issue in content negotiation
Recursively add test dependencies
After this change ParameterContentNegotiationStrategy no longer allows
a null parameter name, ContentNegotiationManagerFactoryBean also
requires it.
Issue: SPR-10139
* 3.2.x:
Exclude spring-build-src from maven publish
Move spring-build-junit into spring-core
Relocate MergePlugin package
Develop a gradle plugin to add test dependencies
Expose Gradle buildSrc for IDE support
Fix [deprecation] compiler warnings
Upgrade to xmlunit version 1.3
Improve 'build' folder ignores
Fix regression in static setter method support
Fix SpEL JavaBean compliance for setters
Conflicts:
spring-beans/src/test/java/org/springframework/beans/ExtendedBeanInfoTests.java
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.
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
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
