Two changes to web.reactive.function:
- Changed Response.stream method to allow for specific Publisher types
to be returned in Response.
- Router now stores HttpMessageReader|Writer retrieved from
Configuration in the attributes as supplier, not as stream, to allow
for multiple reads.
Prior to this commit, the resource handling chain and its
`ResourceResolvers` would use specific `Resource` implementations in
order to add resource metadata to the HTTP response. For example,
`VersionedResource` and `EncodedResource` are both adding specific HTTP
response headers.
This commit aims at making this mechanism more stable and reusable,
since the previous implementation would fail in case a resolved resource
would be both a `VersionedResource` wrapping a `EncodedResource` (or the
other way arount). Only one of the specific implementations would
contribute its metadata since the code supporting that in
`ResourceHttpRequestHandler` would only check for `instanceof` tests,
whereas those implementations are acutally delegating calls to
the wrapped resource.
Now both `VersionedResource` and `EncodedResource` have been replaced by
specific implementations of `ResolvedResource`, which directly provides
those HTTP response headers as part of `getResponseHeaders()`.
This commit applies the same changes for the web reactive
implementations and its `ResourceWebHandler`.
Issue: SPR-14264
Since SPR-14522, the web reactive framework supports checkNotModified
features. This commit aligns the existing MVC infrastructure with
web reactive's behavior.
Because of the new Servlet 3.0 baseline, some constraints
aren't relevant anymore and duplicate code has been removed in
`HttpEntityMethodProcessor`.
Issue: SPR-14659
A straight-forward port of the resource handling support in
spring-webmvc to spring-web-reactive. Primarily adapting contracts and
implementations to use the reactive request and response and the
reactive ResourceHttpMessageWriter.
Issue: SPR-14521
Whereas the existing TestContextConcurrencyTests verify support for
concurrency in the TestContextManager and TestContext, this commit
introduces SpringJUnit4ConcurrencyTests that verify support for
concurrent test execution in Spring's JUnit 4 support, namely in the
SpringRunner, SpringClassRule, and SpringMethodRule.
The tests executed by this new test class come from a hand-picked
collection of test classes within the test suite that is intended to
cover most categories of tests that are currently supported by the
TestContext Framework on JUnit 4.
Note, however, that the chosen test classes intentionally do not
include any classes that fall under the following categories.
- tests that make use of Spring's @DirtiesContext support
- tests that make use of JUnit 4's @FixMethodOrder support
- tests that commit changes to the state of a shared in-memory database
Issue: SPR-5863
This commit improves the exception message thrown when a test's
ApplicationContext is no longer active by explaining that the cause
may be due to parallel test execution.
Issue: SPR-5863
As per specification "The Subscription MUST allow the Subscriber to
call Subscription.request synchronously from within onNext or
onSubscribe". With the current implementation if Subscription.request
is called more than once when Subscriber.onSubscribe ISE will be
thrown - java.lang.IllegalStateException: DEMAND.
With this fix the implementation will not throw ISE and will allow
many invocations of Subscription.request when
Subscriber.onSubscribe.
This commit fixes `ResponseEntityResultHandler` so that it only tries to
call `writeBody` if the `ResponseEntity` is not null. In case the
response entity body is null, the response is flushed right away and the
request is signaled as handled.
Issue: SPR-14663
Prior to this commit, executing tests concurrently in the TestContext
Framework (TCF) was unsupported and typically lead to unpredictable
results.
This commit addresses this core issue by supporting concurrent
execution in the TestContextManager and the DefaultTestContext.
Specifically, the TestContextManager now uses ThreadLocal storage for
the current TestContext, thereby ensuring that any registered
TestExecutionListeners and the TestContextManager itself operate on a
TestContext specific to the current thread.
In order to avoid repeatedly incurring the costs of the overhead of the
TCF bootstrapping process, the original TestContext built by the
TestContextBootstrapper is used as a template which is then passed to
the copy constructor of the concrete implementation of the TestContext
to create the context for the current thread. DefaultTestContext now
implements such a copy constructor, and all concrete implementations of
TestContext are encouraged to do the same.
If the TestContext built by the TestContextBootstrapper does not
provide a copy constructor, thread-safety and support for concurrency
are left completely to the implementation of the concrete TestContext.
Note, however, that this commit does not address any thread-safety or
concurrency issues in the ContextLoader SPI or its implementations.
Issue: SPR-5863
This commit inlines the basic implementation of AttributeAccessorSupport
and converts the LinkedHashMap to a ConcurrentHashMap.
In addition, attributes are now included in toString().
Issue: SPR-5863
This change puts the MockHttpServerRequest/Response under
org.springframework.mock.http.server.reactive.test which
mirrors the arrangement we have with the Servlet mock equivalents
and sets up the addition of MockHttpServerRequest/Response in
spring-test.
Issue: SPR-14421
This commit documents the regexp support in `AntPathMatcher` when
matching for URL patterns. This support is also mentioned in places
where developers can register patterns for ViewControllers or resource
handlers.
Issue: SPR-14652
This commit avoid merging automatically the SSE stream with
Flux.never(). Since browsers automatically reconnect when
the HTTP connection is closed, it is now the user responsability
to optionally perform a concatWith(Flux.never()) on streams that
complete in order to avoid receiving the data multiple times on
client side.
The behavior with hot streams that never complete does not change.
Issue: SPR-14578
This commit adds a "spring-context-indexer" module that can be added to
any project in order to generate an index of candidate components defined
in the project.
`CandidateComponentsIndexer` is a standard annotation processor that
looks for source files with target annotations (typically `@Component`)
and references them in a `META-INF/spring.components` generated file.
Each entry in the index is the fully qualified name of a candidate
component and the comma-separated list of stereotypes that apply to that
candidate. A typical example of a stereotype is `@Component`. If a
project has a `com.example.FooService` annotated with `@Component` the
following `META-INF/spring.components` file is generated at compile time:
```
com.example.FooService=org.springframework.stereotype.Component
```
A new `@Indexed` annotation can be added on any annotation to instructs
the scanner to include a source file that contains that annotation. For
instance, `@Component` is meta-annotated with `@Indexed` now and adding
`@Indexed` to more annotation types will transparently improve the index
with additional information. This also works for interaces or parent
classes: adding `@Indexed` on a `Repository` base interface means that
the indexed can be queried for its implementation by using the fully
qualified name of the `Repository` interface.
The indexer also adds any class or interface that has a type-level
annotation from the `javax` package. This includes obviously JPA
(`@Entity` and related) but also CDI (`@Named`, `@ManagedBean`) and
servlet annotations (i.e. `@WebFilter`). These are meant to handle
cases where a component needs to identify candidates and use classpath
scanning currently.
If a `package-info.java` file exists, the package is registered using
a "package-info" stereotype.
Such files can later be reused by the `ApplicationContext` to avoid
using component scan. A global `CandidateComponentsIndex` can be easily
loaded from the current classpath using `CandidateComponentsIndexLoader`.
The core framework uses such infrastructure in two areas: to retrieve
the candidate `@Component`s and to build a default `PersistenceUnitInfo`.
Rather than scanning the classpath and using ASM to identify candidates,
the index is used if present.
As long as the include filters refer to an annotation that is directly
annotated with `@Indexed` or an assignable type that is directly
annotated with `@Indexed`, the index can be used since a dedicated entry
wil be present for that type. If any other unsupported include filter is
specified, we fallback on classpath scanning.
In case the index is incomplete or cannot be used, The
`spring.index.ignore` system property can be set to `true` or,
alternatively, in a "spring.properties" at the root of the classpath.
Issue: SPR-11890
Arjen Poutsma
Brian Clozel
Artem Yakshin
Stephane Nicoll
nkjackzhang
Rossen Stoyanchev
Sam Brannen
Sebastien Deleuze
Violeta Georgieva
Rob Winch
sylvainlaurent