anchor.diff:  }
   ----
   
  -
  -
  -Spring Cloud Stream provides support for Avro-based converters and schema evolution. See <<schema-evolution>>
  +Spring Cloud Stream also provides support for Avro-based converters and schema evolution.
  +See <<schema-evolution,the specific section>> for details.
   
   === `@StreamListener` and Message Conversion
   
  
positive.code: 
  If you have enabled Avro based schema registry client by setting `spring.cloud.stream.bindings.output.contentType=application/*+avro` you can customize the behavior of the registration with the following properties.
  
  dynamicSchemaGenerationEnabled:: Enable if you want the converter to use reflection to infer a Schema from a POJO.
  +
  Default:: `false`
  +
  readerSchema:: Avro compares schema versions by looking at a writer schema (origin payload) and a reader schema (your application payload), check https://avro.apache.org/docs/1.7.6/spec.html[Avro] documentation for more information. If set, this overrides any lookups at the schema server and uses the local schema as the reader schema.
  Default:: `null`
  +
  schemaLocations:: Register any `.avsc` files listed in this property with the Schema Server.
  +
  Default:: `empty`
  +
  prefix:: The prefix to be used on the Content-Type header
  +
  Default:: `vnd`
  +
  
  === How Schema Registration works in Spring Cloud Stream
  
  To better understand how does Spring Cloud Stream registers new schemas, and uses Avro schema comparison we split the process into two steps described below, one for the registration part, and one for the resolution of schemas.
  
  
  ==== Schema Registration Process (Serialization)
  
  The first part of the registration process is extracting a schema from the payload that is being sent over a channel.
  If you are using Avro types such as SpecificRecord or GenericRecord, those types already contain the schema so we just access that, in case of POJOs we only infer a schema if the property `spring.cloud.stream.schema.avro/dynamicSchemaGenerationEnabled` is set to `true`.
  
  
  .Schema Writer Resolution Process
  image::schema_resolution.png[width=300,scaledwidth="75%",align="center"]
  
  
  Once a schema is obtained, the converter will then load it's metadata (version) from the remote server.
  First it queries a local cache, and if not found it then submits the data to the server that will reply with versioning information.
  We always cache the results to avoid the overhead of querying the Schema Server for every new message that needs to be serialized.
  
  .Schema Registration Process
  image::registration.png[width=300,scaledwidth="75%",align="center"]
  
  With the schema version information, the converter sets the content type of the message to carry the version information such as `application/vnd.user.v1+avro`
  
  ==== Schema Resolution Process (Deserialization)
  
  When reading messages that contains version information, the converter will query the Schema server to fetch the *writer* schema of the message.
  Once it has found the correct schema of the incoming message, it then resolves the reader schema and using Avro evolution support reads it into the reader definition (setting defaults and missing properties)
  
  .Schema Reading Resolution Process
  image::schema_reading.png[width=300,scaledwidth="75%",align="center"]
  
negative.code: [NOTE]
  ====
  It's important to understand the difference between a writer schema (the application that wrote the message) and a reader schema (the receiving application).
  Please take a moment to read https://avro.apache.org/docs/1.7.6/spec.html[the Avro terminology] and understand the process.
  Spring Cloud Stream will always fetch the writer schema to determine how to read a message. If you want to get Avro's schema evolution support working you need to make sure that a readerSchema was properly set for your application.
  ====
  
  
  