anchor.diff:  
   The preceding code is perfectly valid. It compiles and deploys without any issues, yet it never produces the result you expect.
   
  -That is because you are testing something that does not yet exist in a state you expect. That is becouse the payload of the message is not yet converted from the
  +That is because you are testing something that does not yet exist in a state you expect. That is because the payload of the message is not yet converted from the
   wire format (`byte[]`) to the desired type.
   In other words, it has not yet gone through the type conversion process described in the <<Content Type Negotiation>>.
   
  
positive.code: 
  NOTE: At the moment, dispatching through `@StreamListener` conditions is supported only for channel-based binders (not for reactive programming)
  support.
  
  [[spring-cloud-streams-overview-using-polled-consumers]]
  ==== Using Polled Consumers
  
negative.code: in its internal implementation on an already established and popular implementation of Enterprise Integration Patterns within the Spring portfolio of projects:
  https://projects.spring.io/spring-integration/[Spring Integration] framework.
  
  So its only natural for it to support the foundation, semantics, and configuration options that are already established by Spring Integration
  
  For example, you can attach the output channel of a `Source` to a `MessageSource` and use the familiar `@InboundChannelAdapter` annotation, as follows:
  
  