anchor.diff:  @SpringBootApplication
   public static class SupplierConfiguration {
   
  -	@Pollable
  +	@PollableBean
   	public Supplier<Flux<String>> stringSupplier() {
   		return () -> Flux.just("hello", "bye");
   	}
   }
   ----
   
  -The bean itself is annotated with `Pollable` annotation (sub-set of `@Bean`), thus signaling to the framework that although the implementation
  +The bean itself is annotated with `PollableBean` annotation (sub-set of `@Bean`), thus signaling to the framework that although the implementation
   of such a supplier is reactive, it still needs to be polled.
   
   ====== Polling Configuration Properties
  
positive.code: 
  ==== Binding and Binding names
  
  Binding is an abstraction that represents a bridge between remote destinations exposed by the binder and user code,
  This abstraction has a name and while we try to do our best to limit configuration required to run spring-cloud-stream applications,
  being aware of such name(s) is necessary for most cases, since binding names are part of the configuration property name for a specific binding.
  
  Throughout this manual you will see examples of configuration properties such as `spring.cloud.stream.bindings.input.destination=myQueue`.
  The `input` segment in this property name example is what we refer to as _binding name_ and it could derive via several mechanisms.
  The following sub-sections will describe the naming conventions and configuration elements used by spring-cloud-stream to control binding names.
  
  ===== Functional binding names
  
  Unlike the explicit annotation-based support (legacy) used in the previous versions of spring-cloud-stream, the functional
  programming model follows a simple convention when it comes to binding names thus greatly simplifying application configuration.
  Let's look at the first example:
  
  
negative.code: }
  ----
  
  In the preceding example we have an application with a single function which acts as message handler. As a `Function` it has an
  input and output.
  The naming convention used to name input and output bindings is as follows:
  
  * input - `<functionName> + -in- + <index>`
  * output - `<functionName> + -out- + <index>`
  
  The `in` and `out` corresponds to the type of binding (such as _input_ or _output_).
  The `index` is the index of the input or output binding. It is always 0 for typical single input/output function,
  so it's only relevant for <<Functions with multiple input and output arguments>>.
  
  So if for example you would want to map the input of this function to a remote
  destination (e.g., topic, queue etc) called "my-topic" you would do so with the following property:
  ----
  --spring.cloud.stream.bindings.uppercase-in-0.destination=my-topic
  ----
  Note how `uppercase-in-0` is used as a segment in property name. The same goes for `uppercase-out-0`.
  
  ***Descriptive Binding Names***
  
  Some times to improve readability you may want to give your binding a more descriptive names (such as 'account', 'orders` etc).
  You can do it with `spring.cloud.stream.function.bindings.<binding-name>` property.
  
  For example,
  ----
  --spring.cloud.stream.function.bindings.uppercase-in-0=input`
  ----
  
  In the preceding example you mapped and effectively renamed `uppercase-in-0` binding name to `input`. Now all configuration
  properties can refer to `input` binding name instead (e.g.,  `--spring.cloud.stream.bindings.input.destination=my-topic`).
  
  For more on properties and other configuration options please see <<Configuration Options>> section.
  
  