GH-2102 Remove legacy annotation binding documentation

Resolves #2102
This commit is contained in:
Oleg Zhurakousky
2021-02-08 15:50:56 +01:00
parent 4536b97269
commit a550d61af6

View File

@@ -335,86 +335,6 @@ where you are clearly correlating the input of `uppercase` function to `sample-t
For more on properties and other configuration options please see <<Configuration Options>> section.
===== Annotation-based binding names (legacy)
In previous versions of spring-cloud-stream _binding_ names and in fact implementations, derived from the `@EnableBinding`
annotation which typically would take one or more interface classes as parameters. The parameters are referred to
as _bindings_, and they contain methods representing _bindable components_.
For compliance with legacy style applications we still support this annotation-based programming model and you can get more information about it in
<<Annotation-based support (legacy)>> section (sub-section of the <<Programming Model>> section).
Spring Cloud Stream already provides _binding_ interfaces for typical message exchange contracts, which include:
* *Sink:* Identifies the contract for the message consumer by providing the destination from which the message is consumed.
* *Source:* Identifies the contract for the message producer by providing the destination to which the produced message is sent.
* *Processor:* Encapsulates both the sink and the source contracts by exposing two destinations that allow consumption and production of messages.
[source, java]
----
public interface Sink {
String INPUT = "input";
@Input(Sink.INPUT)
SubscribableChannel input();
}
----
[source, java]
----
public interface Source {
String OUTPUT = "output";
@Output(Source.OUTPUT)
MessageChannel output();
}
----
[source, java]
----
public interface Processor extends Source, Sink {}
----
And you can define your own interfaces as well
[source, java]
----
public interface MyBinding {
String FOO = "foo";
@Output(MyBinding.FOO)
MessageChannel foo();
}
----
NOTE: The reason why `@EnableBinding` and binding interfaces are not required with functional programming model is because
they could be derived from the type of functional interface itself. For example, _Processor = Function_, _Source = Supplier_
and so on.
*Pollable Destination Binding*
While the previously described bindings support event-based message consumption, sometimes you need more control, such as rate of consumption.
Starting with version 2.0, you can now bind a pollable consumer:
The following example shows how to bind a pollable consumer:
[source, java]
----
public interface PolledBarista {
@Input
PollableMessageSource orders();
. . .
}
----
In this case, an implementation of `PollableMessageSource` is bound to the `orders` “channel”. See <<Using Polled Consumers>> for more details.
[[spring-cloud-stream-overview-producing-consuming-messages]]
=== Producing and Consuming Messages