From bcf5a6aafa367dee0d5939c8ad4a7688f0487982 Mon Sep 17 00:00:00 2001 From: Eduardo Pinto Date: Sun, 28 Oct 2018 01:10:23 +0000 Subject: [PATCH] GH-840: Fix typos in documentation of Filtering Messages and Retrying Deliveries Fixes GH-840 (https://github.com/spring-projects/spring-kafka/issues/840) * remove reference to FilteringAcknowledgingMessageListenerAdapter * remove reference to RetryingAcknowledgingMessageListenerAdapter --- src/reference/asciidoc/kafka.adoc | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/src/reference/asciidoc/kafka.adoc b/src/reference/asciidoc/kafka.adoc index bc5c2349..cadb3a25 100644 --- a/src/reference/asciidoc/kafka.adoc +++ b/src/reference/asciidoc/kafka.adoc @@ -1461,10 +1461,8 @@ http://docs.spring.io/spring-integration/reference/html/messaging-endpoints-chap The Spring for Apache Kafka project also provides some assistance by means of the `FilteringMessageListenerAdapter` class, which can wrap your `MessageListener`. This class takes an implementation of `RecordFilterStrategy` where you implement the `filter` method to signal -that a message is a duplicate and should be discarded. - -A `FilteringAcknowledgingMessageListenerAdapter` is also provided for wrapping an `AcknowledgingMessageListener`. -This has an additional property `ackDiscarded` which indicates whether the adapter should acknowledge the discarded record; it is `true` by default. +that a message is a duplicate and should be discarded. This has an additional property `ackDiscarded` which indicates +whether the adapter should acknowledge the discarded record; it is `false` by default. When using `@KafkaListener`, set the `RecordFilterStrategy` (and optionally `ackDiscarded`) on the container factory and the listener will be wrapped in the appropriate filtering adapter. @@ -1489,7 +1487,7 @@ When using `@KafkaListener`, set the `RetryTemplate` (and optionally `recoveryCa The contents of the `RetryContext` passed into the `RecoveryCallback` will depend on the type of listener. The context will always have an attribute `record` which is the record for which the failure occurred. If your listener is acknowledging and/or consumer aware, additional attributes `acknowledgment` and/or `consumer` will be available. -For convenience, the `RetryingAcknowledgingMessageListenerAdapter` provides static constants for these keys. +For convenience, the `RetryingMessageListenerAdapter` provides static constants for these keys. See its javadocs for more information. A retry adapter is not provided for any of the batch <> because the framework has no knowledge of where, in a batch, the failure occurred.