Adjust image-width

spring-cloud-stream-core-docs/src/main/asciidoc/spring-cloud-stream-overview.adoc

@@ -93,7 +93,7 @@ The application communicates with the outside world through input and output cha
 Channels are connected to external brokers through middleware-specific Binder implementations.
 
 .Spring Cloud Stream Application
-image::SCSt-with-binder.png[width=300,scaledwidth="50%"]
+image::SCSt-with-binder.png[width=800,scaledwidth="75%",align="center"]
 
 ==== Fat JAR
 
@@ -124,7 +124,7 @@ Communication between applications follows a publish-subscribe model, where data
 This can be seen in the following figure, which shows a typical deployment for a set of interacting Spring Cloud Stream applications.
 
 .Spring Cloud Stream Publish-Subscribe
-image::SCSt-sensors.png[width=300,scaledwidth="50%"]
+image::SCSt-sensors.png[width=800,scaledwidth="75%",align="center"]
 
 Data reported by sensors to an HTTP endpoint is sent to a common destination named `raw-sensor-data`.
 From the destination, it is independently processed by a microservice application that computes time-windowed averages and by another microservice application that ingests the raw data into HDFS (Hadoop Distributed File System).
@@ -149,7 +149,7 @@ Each consumer binding can use the `spring.cloud.stream.bindings.<channelName>.gr
 For the consumers shown in the following figure, this property would be set as `spring.cloud.stream.bindings.<channelName>.group=hdfsWrite` or `spring.cloud.stream.bindings.<channelName>.group=average`.
 
 .Spring Cloud Stream Consumer Groups
-image::SCSt-groups.png[width=300,scaledwidth="50%"]
+image::SCSt-groups.png[width=800,scaledwidth="75%",align="center"]
 
 All groups that subscribe to a given destination receive a copy of published data, but only one member of each group receives a given message from that destination.
 By default, when a group is not specified, Spring Cloud Stream assigns the application to an anonymous and independent single-member consumer group that is in a publish-subscribe relationship with all other consumer groups.
@@ -194,7 +194,7 @@ Spring Cloud Stream provides a common abstraction for implementing partitioned p
 Partitioning can thus be used whether the broker itself is naturally partitioned (for example, Kafka) or not (for example, RabbitMQ).
 
 .Spring Cloud Stream Partitioning
-image::SCSt-partitioning.png[width=300,scaledwidth="50%"]
+image::SCSt-partitioning.png[width=800,scaledwidth="75%",align="center"]
 
 Partitioning is a critical concept in stateful processing, where it is critical (for either performance or consistency reasons) to ensure that all related data is processed together.
 For example, in the time-windowed average calculation example, it is important that all measurements from any given sensor are processed by the same application instance.
@@ -675,7 +675,7 @@ the error back to the messaging system (re-queue, DLQ, and others).
 There are two types of application-level error handling. Errors can be handled at each binding subscription or a global handler can handle all the binding subscription errors. Let's review the details.
 
 .A Spring Cloud Stream Sink Application with Custom and Global Error Handlers
-image::custom_vs_global_error_channels.png[width=300,scaledwidth="75%",align="center"]
+image::custom_vs_global_error_channels.png[width=800,scaledwidth="75%",align="center"]
 
 For each input binding, Spring Cloud Stream creates a dedicated error channel with the following semantics `<destinationName>.errors`.
 
@@ -1207,7 +1207,7 @@ This section provides information about the main concepts behind the Binder SPI,
 The following image shows the general relationship of producers and consumers:
 
 .Producers and Consumers
-image::producers-consumers.png[width=300,scaledwidth="75%"]
+image::producers-consumers.png[width=800,scaledwidth="75%",align="center"]
 
 A producer is any component that sends messages to a channel.
 The channel can be bound to an external message broker with a `Binder` implementation for that broker.
@@ -1371,6 +1371,9 @@ You can add the Actuator dependency as follows:
 </dependency>
 ----
 
+NOTE: To run Spring Cloud Stream 2.0 apps in Cloud Foundry, you must add `spring-boot-starter-web` and `spring-boot-starter-actuator` to the classpath. Otherwise, the
+application will not start due to health check failures.
+
 You must also enable the `bindings` actuator endpoints by setting the following property: `--management.endpoints.web.exposure.include=bindings`.
 
 Once those prerequisites are satisfied. you should see the following in the logs when application start:
@@ -2235,14 +2238,14 @@ Avro types such as `SpecificRecord` or `GenericRecord` already contain a schema,
 In the case of POJOs, a schema is inferred if the `spring.cloud.stream.schema.avro.dynamicSchemaGenerationEnabled` property is set to `true` (the default).
 
 .Schema Writer Resolution Process
-image::schema_resolution.png[width=300,scaledwidth="75%",align="center"]
+image::schema_resolution.png[width=800,scaledwidth="75%",align="center"]
 
 Ones a schema is obtained, the converter loads its metadata (version) from the remote server.
 First, it queries a local cache. If no result is found, it submits the data to the server, which replies with versioning information.
 The converter always caches 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"]
+image::registration.png[width=800,scaledwidth="75%",align="center"]
 
 With the schema version information, the converter sets the `contentType` header of the message to carry the version information -- for example: `application/vnd.user.v1+avro`.
 
@@ -2253,7 +2256,7 @@ When reading messages that contain version information (that is, a `contentType`
 Once it has found the correct schema of the incoming message, it retrieves the reader schema and, by using Avro's schema resolution support, reads it into the reader definition (setting defaults and any missing properties).
 
 .Schema Reading Resolution Process
-image::schema_reading.png[width=300,scaledwidth="75%",align="center"]
+image::schema_reading.png[width=800,scaledwidth="75%",align="center"]
 
 NOTE: You should understand the difference between a writer schema (the application that wrote the message) and a reader schema (the receiving application).
 We suggest taking a moment to read https://avro.apache.org/docs/1.7.6/spec.html[the Avro terminology] and understand the process.