Spring/spring-kafka
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Fix plural words rendering in docs

Browse Source 
The document contains words written in plural form, so I think we can avoid the plural form by using double back-ticks instead of spaces.

Signed-off-by: Tran Ngoc Nhan <ngocnhan.tran1996@gmail.com>
This commit is contained in:
Tran Ngoc Nhan
2025-04-22 21:38:40 +07:00
committed by GitHub
parent 88c45cc44b
commit 4272118e35
5 changed files with 24 additions and 24 deletions
Download Patch File Download Diff File Expand all files Collapse all files

38
spring-kafka-docs/src/main/antora/modules/ROOT/pages/appendix/change-history.adoc
View File

@@ -320,14 +320,14 @@ See xref:kafka/container-props.adoc[Listener Container Properties] for more info
[[x30-template-changes]]
=== `KafkaTemplate` Changes
The futures returned by this class are now `CompletableFuture` s instead of `ListenableFuture` s.
The futures returned by this class are now ``CompletableFuture``s instead of ``ListenableFuture``s.
See xref:kafka/sending-messages.adoc#kafka-template[Using `KafkaTemplate`].
[[x30-rkt-changes]]
=== `ReplyingKafkaTemplate` Changes
The futures returned by this class are now `CompletableFuture` s instead of `ListenableFuture` s.
See xref:kafka/sending-messages.adoc#replying-template[Using `ReplyingKafkaTemplate`] and xref:kafka/sending-messages.adoc#exchanging-messages[Request/Reply with `Message<?>` s].
The futures returned by this class are now ``CompletableFuture``s instead of ``ListenableFuture``s.
See xref:kafka/sending-messages.adoc#replying-template[Using `ReplyingKafkaTemplate`] and xref:kafka/sending-messages.adoc#exchanging-messages[Request/Reply with ``Message<?>``s].
[[x30-listener]]
=== `@KafkaListener` Changes
@@ -395,7 +395,7 @@ See xref:kafka/headers.adoc[Message Headers] for more information.
[[x29-template-changes]]
=== `KafkaTemplate` Changes
In 3.0, the futures returned by this class will be `CompletableFuture` s instead of `ListenableFuture` s.
In 3.0, the futures returned by this class will be ``CompletableFuture``s instead of ``ListenableFuture``s.
See xref:kafka/sending-messages.adoc#kafka-template[Using `KafkaTemplate`] for assistance in transitioning when using this release.
[[x29-rkt-changes]]
@@ -405,8 +405,8 @@ The template now provides a method to wait for assignment on the reply container
Also available in version 2.8.8 or later.
See xref:kafka/sending-messages.adoc#replying-template[Using `ReplyingKafkaTemplate`].
In 3.0, the futures returned by this class will be `CompletableFuture` s instead of `ListenableFuture` s.
See xref:kafka/sending-messages.adoc#replying-template[Using `ReplyingKafkaTemplate`] and xref:kafka/sending-messages.adoc#exchanging-messages[Request/Reply with `Message<?>` s] for assistance in transitioning when using this release.
In 3.0, the futures returned by this class will be ``CompletableFuture``s instead of ``ListenableFuture``s.
See xref:kafka/sending-messages.adoc#replying-template[Using `ReplyingKafkaTemplate`] and xref:kafka/sending-messages.adoc#exchanging-messages[Request/Reply with ``Message<?>``s] for assistance in transitioning when using this release.
[[what-s-new-in-2-8-since-2-7]]
== What's New in 2.8 Since 2.7
@@ -474,7 +474,7 @@ See xref:kafka/annotation-error-handling.adoc#error-handlers[Container Error Han
The `interceptBeforeTx` container property is now `true` by default.
The `authorizationExceptionRetryInterval` property has been renamed to `authExceptionRetryInterval` and now applies to `AuthenticationException` s in addition to `AuthorizationException` s previously.
The `authorizationExceptionRetryInterval` property has been renamed to `authExceptionRetryInterval` and now applies to ``AuthenticationException``s in addition to ``AuthorizationException``s previously.
Both exceptions are considered fatal and the container will stop by default, unless this property is set.
See xref:kafka/receiving-messages/message-listener-container.adoc#kafka-container[Using `KafkaMessageListenerContainer`] and xref:kafka/container-props.adoc[Listener Container Properties] for more information.
@@ -537,7 +537,7 @@ See xref:kafka/container-props.adoc[Listener Container Properties] for more info
Error handlers that use a `BackOff` between delivery attempts (e.g. `SeekToCurrentErrorHandler` and `DefaultAfterRollbackProcessor`) will now exit the back off interval soon after the container is stopped, rather than delaying the stop.
Error handlers and after rollback processors that extend `FailedRecordProcessor` can now be configured with one or more `RetryListener` s to receive information about retry and recovery progress.
Error handlers and after rollback processors that extend `FailedRecordProcessor` can now be configured with one or more ``RetryListener``s to receive information about retry and recovery progress.
The `RecordInterceptor` now has additional methods called after the listener returns (normally, or by throwing an exception).
It also has a sub-interface `ConsumerAwareRecordInterceptor`.
@@ -578,7 +578,7 @@ See xref:kafka/transactions.adoc[Transactions] for more information.
There is now a mechanism to examine a reply and fail the future exceptionally if some condition exists.
Support for sending and receiving `spring-messaging` `Message<?>` s has been added.
Support for sending and receiving `spring-messaging` ``Message<?>``s has been added.
See xref:kafka/sending-messages.adoc#replying-template[Using `ReplyingKafkaTemplate`] for more information.
@@ -602,9 +602,9 @@ It is now possible to add a `spring-messaging` `SmartMessageConverter` to the `M
See xref:kafka/serdes.adoc#messaging-message-conversion[Spring Messaging Message Conversion] for more information.
[[x27-sequencing]]
=== Sequencing `@KafkaListener` s
=== Sequencing ``@KafkaListener``s
See xref:kafka/receiving-messages/sequencing.adoc[Starting `@KafkaListener` s in Sequence] for more information.
See xref:kafka/receiving-messages/sequencing.adoc[Starting ``@KafkaListener``s in Sequence] for more information.
[[x27-exp-backoff]]
=== `ExponentialBackOffWithMaxRetries`
@@ -638,7 +638,7 @@ In addition, you can now select the `BackOff` to use based on the failed record
You can now configure an `adviceChain` in the container properties.
See xref:kafka/container-props.adoc[Listener Container Properties] for more information.
When the container is configured to publish `ListenerContainerIdleEvent` s, it now publishes a `ListenerContainerNoLongerIdleEvent` when a record is received after publishing an idle event.
When the container is configured to publish ``ListenerContainerIdleEvent``s, it now publishes a `ListenerContainerNoLongerIdleEvent` when a record is received after publishing an idle event.
See xref:kafka/events.adoc[Application Events] and xref:kafka/events.adoc#idle-containers[Detecting Idle and Non-Responsive Consumers] for more information.
[[kafkalistener-changes]]
@@ -742,7 +742,7 @@ See xref:kafka/annotation-error-handling.adoc#error-handlers[Container Error Han
The `getAssignmentsByClientId()` method has been added, making it easier to determine which consumers in a concurrent container are assigned which partition(s).
See xref:kafka/container-props.adoc[Listener Container Properties] for more information.
You can now suppress logging entire `ConsumerRecord` s in error, debug logs etc.
You can now suppress logging entire ``ConsumerRecord``s in error, debug logs etc.
See `onlyLogRecordMetadata` in xref:kafka/container-props.adoc[Listener Container Properties].
[[x25-template]]
@@ -763,7 +763,7 @@ See xref:kafka/sending-messages.adoc#kafka-template[Using `KafkaTemplate`] for m
[[x25-string-serializer]]
=== Kafka String Serializer/Deserializer
New `ToStringSerializer`/`StringDeserializer` s as well as an associated `SerDe` are now provided.
New `ToStringSerializer`/``StringDeserializer``s as well as an associated `SerDe` are now provided.
See xref:kafka/serdes.adoc#string-serde[String serialization] for more information.
[[x25-json-deser]]
@@ -886,8 +886,8 @@ See xref:kafka/receiving-messages/message-listener-container.adoc#kafka-containe
[[cb-2-2-and-2-3-listener-container-changes]]
=== Listener Container Changes
Previously, error handlers received `ListenerExecutionFailedException` (with the actual listener exception as the `cause`) when the listener was invoked using a listener adapter (such as `@KafkaListener` s).
Exceptions thrown by native `GenericMessageListener` s were passed to the error handler unchanged.
Previously, error handlers received `ListenerExecutionFailedException` (with the actual listener exception as the `cause`) when the listener was invoked using a listener adapter (such as ``@KafkaListener``s).
Exceptions thrown by native ``GenericMessageListener``s were passed to the error handler unchanged.
Now a `ListenerExecutionFailedException` is always the argument (with the actual listener exception as the `cause`), which provides access to the container's `group.id` property.
Because the listener container has it's own mechanism for committing offsets, it prefers the Kafka `ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG` to be `false`.
@@ -914,7 +914,7 @@ See its JavaDocs and xref:kafka/receiving-messages/message-listener-container.ad
When using `AckMode.MANUAL` (or `MANUAL_IMMEDIATE`) you can now cause a redelivery by calling `nack` on the `Acknowledgment`.
See xref:kafka/receiving-messages/message-listener-container.adoc#committing-offsets[Committing Offsets] for more information.
Listener performance can now be monitored using Micrometer `Timer` s.
Listener performance can now be monitored using Micrometer ``Timer``s.
See xref:kafka/micrometer.adoc[Monitoring] for more information.
The containers now publish additional consumer lifecycle events relating to startup.
@@ -942,7 +942,7 @@ See xref:kafka/annotation-error-handling.adoc#dead-letters[Publishing Dead-lette
[[cb-2-2-and-2-3-topicbuilder]]
=== TopicBuilder
A new class `TopicBuilder` is provided for more convenient creation of `NewTopic` `@Bean` s for automatic topic provisioning.
A new class `TopicBuilder` is provided for more convenient creation of `NewTopic` ``@Bean``s for automatic topic provisioning.
See <<configuring-topics>> for more information.
[[cb-2-2-and-2-3-kafka-streams-changes]]
@@ -971,7 +971,7 @@ Also a `JacksonMimeTypeModule` has been introduced for serialization of `org.spr
See its JavaDocs and xref:kafka/serdes.adoc[Serialization, Deserialization, and Message Conversion] for more information.
A `ByteArrayJsonMessageConverter` has been provided as well as a new super class for all Json converters, `JsonMessageConverter`.
Also, a `StringOrBytesSerializer` is now available; it can serialize `byte[]`, `Bytes` and `String` values in `ProducerRecord` s.
Also, a `StringOrBytesSerializer` is now available; it can serialize `byte[]`, `Bytes` and `String` values in ``ProducerRecord``s.
See xref:kafka/serdes.adoc#messaging-message-conversion[Spring Messaging Message Conversion] for more information.
The `JsonSerializer`, `JsonDeserializer` and `JsonSerde` now have fluent APIs to make programmatic configuration simpler.

2
spring-kafka-docs/src/main/antora/modules/ROOT/pages/kafka/container-props.adoc
View File

@@ -158,7 +158,7 @@ The default executor creates threads named `<name>-C-n`; with the `KafkaMessageL
|[[monitorInterval]]<<monitorInterval,`monitorInterval`>>
|30s
|How often to check the state of the consumer threads for `NonResponsiveConsumerEvent` s.
|How often to check the state of the consumer threads for ``NonResponsiveConsumerEvent``s.
See `noPollThreshold` and `pollTimeout`.
|[[noPollThreshold]]<<noPollThreshold,`noPollThreshold`>>

2
spring-kafka-docs/src/main/antora/modules/ROOT/pages/kafka/micrometer.adoc
View File

@@ -117,5 +117,5 @@ To do so, add a custom `KafkaListenerObservationConvention` and/or `KafkaTemplat
The `record` property in both observation contexts contains the `ConsumerRecord` or `ProducerRecord` respectively.
The sender and receiver contexts `remoteServiceName` properties are set to the Kafka `clusterId` property; this is retrieved by a `KafkaAdmin`.
If, for some reason - perhaps lack of admin permissions, you cannot retrieve the cluster id, starting with version 3.1, you can set a manual `clusterId` on the `KafkaAdmin` and inject it into `KafkaTemplate` s and listener containers.
If, for some reason - perhaps lack of admin permissions, you cannot retrieve the cluster id, starting with version 3.1, you can set a manual `clusterId` on the `KafkaAdmin` and inject it into ``KafkaTemplate``s and listener containers.
When it is `null` (default), the admin will invoke the `describeCluster` admin operation to retrieve it from the broker.

2
spring-kafka-docs/src/main/antora/modules/ROOT/pages/kafka/receiving-messages/message-listener-container.adoc
View File

@@ -82,7 +82,7 @@ return container;
Note that when creating a `DefaultKafkaConsumerFactory`, using the constructor that just takes in the properties as above means that key and value `Deserializer` classes are picked up from configuration.
Alternatively, `Deserializer` instances may be passed to the `DefaultKafkaConsumerFactory` constructor for key and/or value, in which case all Consumers share the same instances.
Another option is to provide `Supplier<Deserializer>` s (starting with version 2.3) that will be used to obtain separate `Deserializer` instances for each `Consumer`:
Another option is to provide ``Supplier<Deserializer>``s (starting with version 2.3) that will be used to obtain separate `Deserializer` instances for each `Consumer`:
[source, java]
----

4
spring-kafka-docs/src/main/antora/modules/ROOT/pages/kafka/sending-messages.adoc
View File

@@ -286,7 +286,7 @@ Calling `reset()` or `destroy()` will not clean up these producers.
Also see xref:kafka/transactions.adoc#tx-template-mixed[`KafkaTemplate` Transactional and non-Transactional Publishing].
When creating a `DefaultKafkaProducerFactory`, key and/or value `Serializer` classes can be picked up from configuration by calling the constructor that only takes in a Map of properties (see example in xref:kafka/sending-messages.adoc#kafka-template[Using `KafkaTemplate`]), or `Serializer` instances may be passed to the `DefaultKafkaProducerFactory` constructor (in which case all `Producer` s share the same instances).
When creating a `DefaultKafkaProducerFactory`, key and/or value `Serializer` classes can be picked up from configuration by calling the constructor that only takes in a Map of properties (see example in xref:kafka/sending-messages.adoc#kafka-template[Using `KafkaTemplate`]), or `Serializer` instances may be passed to the `DefaultKafkaProducerFactory` constructor (in which case all ``Producer``s share the same instances).
Alternatively you can provide `Supplier<Serializer>`+++s+++ (starting with version 2.3) that will be used to obtain separate `Serializer` instances for each `Producer`:
[source, java]
@@ -335,7 +335,7 @@ RequestReplyFuture<K, V, R> sendAndReceive(ProducerRecord<K, V> record,
Duration replyTimeout);
----
(Also see xref:kafka/sending-messages.adoc#exchanging-messages[Request/Reply with `Message<?>` s]).
(Also see xref:kafka/sending-messages.adoc#exchanging-messages[Request/Reply with ``Message<?>``s]).
The result is a `CompletableFuture` that is asynchronously populated with the result (or an exception, for a timeout).
The result also has a `sendFuture` property, which is the result of calling `KafkaTemplate.send()`.