List of Figures

Chapter 1. Getting started with Spring

Figure 1.1. Application components are managed and injected into each other by the Spring application context.

Figure 1.2. Starting a new project with the Initializr in Spring Tool Suite

Figure 1.3. Specifying general project information for the Taco Cloud application

Figure 1.4. Choosing starter dependencies

Figure 1.5. Optionally specifying an alternate Initializr address

Figure 1.6. The initial Spring project structure as shown in Spring Tool Suite

Figure 1.7. Highlights of the Spring Boot Dashboard

Figure 1.8. The Taco Cloud homepage

Chapter 2. Developing web applications

Figure 2.1. A typical Spring MVC request flow

Figure 2.2. The rendered taco design page

Figure 2.3. The taco order form

Figure 2.4. Validation errors displayed on the order form

Chapter 3. Working with data

Figure 3.1. The tables for the Taco Cloud schema

Figure 3.2. Spring Data parses repository method signatures to determine the query that should be performed.

Chapter 4. Securing Spring

Figure 4.1. Adding the security starter with Spring Tool Suite

Figure 4.2. Spring Security gives you a plain login page for free.

Chapter 5. Working with configuration properties

Figure 5.1. The Spring environment pulls properties from property sources and makes them available to beans in the application context.

Figure 5.2. A warning for missing configuration property metadata

Figure 5.3. Hover documentation for configuration properties in the Spring Tool Suite

Figure 5.4. Creating configuration property metadata with the quick-fix pop up in Spring Tool Suite

Figure 5.5. Hover help for custom configuration properties

Figure 5.6. Configuration property metadata enables autocompletion of properties.

Chapter 6. Creating REST services

Figure 6.1. The new Taco Cloud home page

Figure 6.2. Displaying the most recently created tacos

Chapter 8. Sending messages asynchronously

Figure 8.1. Messages sent to a RabbitMQ exchange are routed to one or more queues, based on routing keys and bindings.

Figure 8.2. A Kafka cluster is composed of multiple brokers, each acting as a leader for partitions of the topics.

Chapter 9. Integrating Spring

Figure 9.1. The file writer integration flow

Figure 9.2. Message channels are conduits through which data flows between other components in an integration flow.

Figure 9.3. Filters based on some criteria allow or disallow messages from proceeding in the pipeline.

Figure 9.4. Transformers morph messages as they flow through an integration flow.

Figure 9.5. Routers direct messages to different channels, based on some criteria applied to the messages.

Figure 9.6. Splitters break down messages into two or more separate messages that can be handled by separate subflows.

Figure 9.7. Service activators invoke some service by way of a MessageHandler on receipt of a message.

Figure 9.8. Service gateways are interfaces through which an application can submit messages to an integration flow.

Figure 9.9. Channel adapters are the entry and exit points of an integration flow.

Figure 9.10. An integration flow to accept taco orders by email

Chapter 10. Introducing Reactor

Figure 10.1. Marble diagram illustrating the basic flow of a Flux

Figure 10.2. Marble diagram illustrating the basic flow of a Mono

Figure 10.3. A Flux can be created from an array, Iterable, or Stream.

Figure 10.4. Creating a Flux from a range results in a counter-style publishing of messages.

Figure 10.5. A Flux created from an interval has a periodic entry published to it.

Figure 10.6. Merging two Flux streams interleaves their messages into a new Flux.

Figure 10.7. Zipping two Flux streams results in a Flux containing tuples of one element from each Flux.

Figure 10.8. An alternative form of the zip operation results in a Flux of messages created from one element of each incoming Flux.

Figure 10.9. The first operation chooses the first Flux to emit a message and thereafter only produces messages from that Flux.

Figure 10.10. The skip operation skips a specified number of messages before passing the remaining messages on to the resulting Flux.

Figure 10.11. An alternative form of the skip operation waits until some duration has passed before passing messages on to the resulting Flux.

Figure 10.12. The take operation passes only the first so many messages from the incoming Flux and then cancels the subscription.

Figure 10.13. An alternative form of the take operation passes messages on to the resulting Flux until some duration has passed.

Figure 10.14. An incoming Flux can be filtered so that the resulting Flux only receives messages that match a given predicate.

Figure 10.15. The distinct operation filters out any duplicate messages.

Figure 10.16. The map operation performs a transformation of incoming messages into new messages on the resulting stream.

Figure 10.17. The flat map operation uses an intermediate Flux to perform a transformation, consequently allowing for asynchronous transformations.

Figure 10.18. The buffer operation results in a Flux of lists of a given maximum size that are collected from the incoming Flux.

Figure 10.19. The collect-list operation results in a Mono containing a list of all messages emitted by the incoming Flux.

Figure 10.20. The collect-map operation results in a Mono containing a Map of messages emitted by the incoming Flux, where the key is derived from some characteristic of the incoming messages.

Figure 10.21. A flux can be tested to ensure that all messages meet some condition with the all operation.

Figure 10.22. A flux can be tested to ensure that at least one message meets some condition with the any operation.

Chapter 11. Developing reactive APIs

Figure 11.1. Asynchronous web frameworks apply event looping to handle more requests with fewer threads.

Figure 11.2. Spring 5 supports reactive web applications with a new web framework called WebFlux, which is a sibling to Spring MVC and shares many of its core components.

Figure 11.3. To maximize the benefit of a reactive web framework, it should be part of a full end-to-end reactive stack.

Chapter 12. Persisting data reactively

Figure 12.1. Instead of using foreign keys and joins, Cassandra tables are denormalized, with user-defined types containing data copied from related tables.

Chapter 13. Discovering services

Figure 13.1. Services register with the Eureka service registry so that other services can discover and consume them.

Figure 13.2. The Eureka web dashboard

Figure 13.3. When in self-preservation mode, Eureka displays this message in its dashboard.

Figure 13.4. When self-preservation mode is disabled, you’ll get a different message reminding you that self-preservation mode is disabled.

Figure 13.5. The ingredient service as it appears in Eureka’s dashboard

Chapter 14. Managing configuration

Figure 14.1. Spring Cloud Config Server serves configuration properties from a backing Git repository or Vault secret store to other services.

Figure 14.2. Config Server exposes a REST API through which configuration properties can be consumed.

Figure 14.3. Application-specific configuration files have names based on each application’s spring.application.name property.

Figure 14.4. Profile-specific configuration files can be named with a suffix equal to the name of the active profile.

Figure 14.5. Configuration files can be both application-specific and profile-specific.

Figure 14.6. Writing a secret to Vault with the vault command

Figure 14.7. Config Server, along with Spring Cloud Bus, can broadcast changes to applications so that their properties can be refreshed automatically when there are changes.

Figure 14.8. Click the Settings button in Gogs or GitHub to get started creating a webhook.

Figure 14.9. The Add Webhook button under the Webhooks menu opens the form for creating a webhook.

Figure 14.10. To create a webhook, specify the Config Server’s /monitor URL and JSON payload.

Chapter 15. Handling failure and latency

Figure 15.1. The circuit breaker pattern enables graceful failure handling.

Figure 15.2. The Hystrix dashboard homepage

Figure 15.3. The Hystrix stream monitor page shows the metrics from each of an application’s circuit breakers.

Figure 15.4. Each circuit breaker monitor provides useful information regarding the current state of the circuit breaker.

Figure 15.5. Thread pool monitors show vital statistics about each of the Hystrix-managed thread pools.

Figure 15.6. The Hystrix dashboard shows all circuit breakers from all services when pointed at an aggregated Turbine stream.

Chapter 17. Administering Spring

Figure 17.1. The Spring Boot Admin server consumes Actuator endpoints from one or more Spring Boot applications and presents the data in a web-based UI.

Figure 17.2. A newly created server displayed in the Spring Boot Admin UI. No applications are registered yet.

Figure 17.3. The Spring Boot Admin UI displays a single registered application.

Figure 17.4. The Spring Boot Admin UI can show all the services it discovers in Eureka.

Figure 17.5. The Spring Boot Admin UI shows offline services separately from those that are online.

Figure 17.6. The Details tab of the Spring Boot Admin UI displays general health and information about an application.

Figure 17.7. As you scroll down on the Details tab, you can view additional JVM internal information, including processor, thread, and memory statistics.

Figure 17.8. On the Metrics tab, you can set up watches on any metrics published through the application’s /metrics endpoint.

Figure 17.9. The Environment tab displays environment properties and includes options to override and filter those values.

Figure 17.10. The Loggers tab displays logging levels for packages and classes in the application and lets you override those levels.

Figure 17.11. You can use the Threads tab in the Admin UI to keep a live watch on an application’s threads.

Figure 17.12. The HTTP Trace tab tracks recent HTTP traffic to an application, including information regarding requests that resulted in errors.

Figure 17.13. Clicking a request entry on the HTTP Trace tab displays additional details about the request.

Chapter 18. Monitoring Spring with JMX

Figure 18.1. Actuator endpoints are automatically exposed as JMX MBeans.

Figure 18.2. Using JConsole to display logging levels from a Spring Boot application

Figure 18.3. Logging levels from the /loggers endpoint MBean displayed in JConsole

Figure 18.4. TacoCounter’s operations and attributes as seen in JConsole

Figure 18.5. JConsole, subscribed to the TacoCounter MBean, receives a notification for every 100 tacos that are created.

Appendix Appendix. Bootstrapping Spring applications

Figure A.1. Starting a new project in Spring Tool Suite

Figure A.2. Defining basic project information

Figure A.3. Specifying project dependencies

Figure A.4. Optionally specifying the Initializr base URL

Figure A.5. Starting a new Spring project in IntelliJ IDEA

Figure A.6. Selecting the location of the Spring Initializr

Figure A.7. Specifying essential project information in IntelliJ IDEA

Figure A.8. Selecting project dependencies

Figure A.9. Setting the project name and location

Figure A.10. Starting a new Spring project in NetBeans

Figure A.11. Creating a new Spring Boot Initializr project

Figure A.12. Specifying essential project information

Figure A.13. Selecting project dependencies

Figure A.14. Specifying the project’s name and location

Figure A.15. The simple version of the Spring Initializr web interface

Figure A.16. Searching for dependencies

Figure A.17. Selecting dependencies

Figure A.18. The full version of the Initializr user interface