- ScriptedSubscriber has been renamed to Verifier
- The Publisher is passed to create() instead of verify()
- No more need to specify the generic type explicitly
- Version is now sync with reactor-core
Issue: SPR-14800
Reactor recently added the `ScriptedSubscriber` in its new
`reactor-addons` module. This `Subscriber` revissits the previous
`TestSubscriber` with many improvements, including:
* scripting each expectation
* builder API that guides you until the final verification step
* virtual time support
This commit refactor all existing tests to use this new
infrastructure and removed the `TestSubscriber` implementation.
Issue: SPR-14800
This commit removes the usage of Reactor adapters (about to
be moved from Reactor Core to a new Reactor Adapter module).
Instead, RxReactiveStreams is now used for adapting RxJava
1 and Flowable methods are used for RxJava 2.
Issue: SPR-14824
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
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
Due to restrictions imposed by JUnit 4, the SpringClassRule must be
declared as a public static field, which makes it impossible to be
declared directly within a nested (i.e., inner) test class.
This commit demonstrates a work-around that makes it possible to use
the SpringClassRule and SpringMethodRule in a nested (i.e., inner) test
class when using a custom JUnit 4 runner such as the
HierarchicalContextRunner from Stefan Bechtold.
The trick is to have inner test classes extend a class that properly
declares the SpringClassRule and SpringMethodRule. The
SpringRuleConfigurer in this commit serves as an example.
Note, however, that each such nested test class must declare its own
@ContextConfiguration. Furthermore, TestExecutionListeners in the
Spring TestContext Framework are not applied to the enclosing instance
of such an inner test class, meaning that @Autowired fields in the
enclosing instance will not be injected, etc.
Issue: SPR-14150
This commit adds Smile and CBOR Jackson HttpMessageConverters
and make it possible to create Smile and CBOR ObjectMapper via
Jackson2ObjectMapperBuilder, which now allows to specify any
custom JsonFactory.
Like with JSON and XML Jackson support, the relevant
HttpMessageConverters are automaticially configurered by
Spring MVC WebMvcConfigurationSupport if jackson-dataformat-smile
or jackson-dataformat-cbor dependencies are found in the classpath.
Issue: SPR-14435
Since the upgrade to Gradle 3, our Bamboo build is failing because it
can't find test reports "at the usual location".
This commit restores the location that Gradle 2 was using until we
upgrade to a version of Bamboo that supports it.
Issue: SPR-14569
Previously the IDE (STS) was resolving a different reactor-core
version (3.0.0.BUILD-SNAPSHOT) than the build (3.0.0.RELEASE). This
discrepancy was due to the fact that reactor-netty now brings in
reactor-core 3.0.0.RELEASE. Gradle's version conflict resolution is to use
the latest version. However, the optional dependency on reactor-core
3.0.0.BUILD-SNAPSHOT was making the build path of the IDE use the SNAPSHOT.
This fix leverages a resolutionStrategy to ensure a consistent version of
reactor-core is used throughout the entire project. It also bumps up the
reactor-core version to 3.0.0.RELEASE to be consistent with reactor-netty.
Care is taken to only change 3.x vesion since 2.x is still used within
the codebase.
Juergen Hoeller
Sebastien Deleuze
Sam Brannen
Brian Clozel
Rossen Stoyanchev
Stephane Nicoll
Rob Winch