24. What’s New in 2.0?
Spring Cloud Stream introduces a number of new features, enhancements, and changes. The following sections outline the most notable ones:
24.1 New Features and Components
-
Polling Consumers : Introduction of polled consumers, which lets the application control message processing rates. See “Section 27.3.4, “Using Polled Consumers”” for more details. You can also read this blog post for more details.
-
Micrometer Support : Metrics has been switched to use Micrometer .
MeterRegistry
is also provided as a bean so that custom applications can autowire it to capture custom metrics. See “Chapter 35, Metrics Emitter” for more details. -
New Actuator Binding Controls : New actuator binding controls let you both visualize and control the Bindings lifecycle. For more details, see Section 28.6, “Binding visualization and control”.
-
Configurable RetryTemplate : Aside from providing properties to configure
RetryTemplate
, we now let you provide your own template, effectively overriding the one provided by the framework. To use it, configure it as a@Bean
in your application.
24.2 Notable Enhancements
This version includes the following notable enhancements:
24.2.1 Both Actuator and Web Dependencies Are Now Optional
This change slims down the footprint of the deployed application in the event neither actuator nor web dependencies required. It also lets you switch between the reactive and conventional web paradigms by manually adding one of the following dependencies.
The following listing shows how to add the conventional web framework:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
The following listing shows how to add the reactive web framework:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-webflux</artifactId>
</dependency>
The following list shows how to add the actuator dependency:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
24.2.2 Content-type Negotiation Improvements
One of the core themes for verion 2.0 is improvements (in both consistency and performance) around content-type negotiation and message conversion. The following summary outlines the notable changes and improvements in this area. See the “Chapter 30, Content Type Negotiation” section for more details. Also this blog post contains more detail.
-
All message conversion is now handled only by
MessageConverter
objects. -
We introduced the
@StreamMessageConverter
annotation to provide customMessageConverter
objects. -
We introduced the default
Content Type
asapplication/json
, which needs to be taken into consideration when migrating 1.3 application or operating in the mixed mode (that is, 1.3 producer → 2.0 consumer). -
Messages with textual payloads and a
contentType
oftext/…
or…/json
are no longer converted toMessage<String>
for cases where the argument type of the providedMessageHandler
can not be determined (that is,public void handle(Message<?> message)
orpublic void handle(Object payload)
). Furthermore, a strong argument type may not be enough to properly convert messages, so thecontentType
header may be used as a supplement by someMessageConverters
.
24.3 Notable Deprecations
As of version 2.0, the following items have been deprecated:
24.3.1 Java Serialization (Java Native and Kryo)
JavaSerializationMessageConverter
and KryoMessageConverter
remain for now. However, we plan to move them out of the core packages and support in the future. The main reason for this deprecation is to flag the issue that type-based, language-specific serialization could cause in distributed environments, where Producers and Consumers may depend on different JVM versions or have different versions of supporting libraries (that is, Kryo). We also wanted to draw the attention to the fact that Consumers and Producers may not even be Java-based, so polyglot style serialization (i.e., JSON) is better suited.
24.3.2 Deprecated Classes and Methods
The following is a quick summary of notable deprecations. See the corresponding [javadoc] for more details.
-
SharedChannelRegistry
. UseSharedBindingTargetRegistry
. -
Bindings
. Beans qualified by it are already uniquely identified by their type — for example, providedSource
,Processor
, or custom bindings:
public interface Sample {
String OUTPUT = "sampleOutput";
@Output(Sample.OUTPUT)
MessageChannel output();
}
-
HeaderMode.raw
. Usenone
,headers
orembeddedHeaders
-
ProducerProperties.partitionKeyExtractorClass
in favor ofpartitionKeyExtractorName
andProducerProperties.partitionSelectorClass
in favor ofpartitionSelectorName
. This change ensures that both components are Spring configured and managed and are referenced in a Spring-friendly way. -
BinderAwareRouterBeanPostProcessor
. While the component remains, it is no longer aBeanPostProcessor
and will be renamed in the future. -
BinderProperties.setEnvironment(Properties environment)
. UseBinderProperties.setEnvironment(Map<String, Object> environment)
.
This section goes into more detail about how you can work with Spring Cloud Stream. It covers topics such as creating and running stream applications.