diff --git a/framework-docs/modules/ROOT/pages/core/aop.adoc b/framework-docs/modules/ROOT/pages/core/aop.adoc index 2ab5709520..be7e6b7d96 100644 --- a/framework-docs/modules/ROOT/pages/core/aop.adoc +++ b/framework-docs/modules/ROOT/pages/core/aop.adoc @@ -3173,7 +3173,7 @@ code snippet shows: If you invoke a method on an object reference, the method is invoked directly on that object reference, as the following image and listing show: -image::images/aop-proxy-plain-pojo-call.png[] +image::aop-proxy-plain-pojo-call.png[] [source,java,indent=0,subs="verbatim",role="primary"] .Java @@ -3200,7 +3200,7 @@ image::images/aop-proxy-plain-pojo-call.png[] Things change slightly when the reference that client code has is a proxy. Consider the following diagram and code snippet: -image::images/aop-proxy-call.png[] +image::aop-proxy-call.png[] [source,java,indent=0,subs="verbatim",role="primary"] .Java diff --git a/framework-docs/modules/ROOT/pages/core/beans.adoc b/framework-docs/modules/ROOT/pages/core/beans.adoc index 3afd909655..064d837633 100644 --- a/framework-docs/modules/ROOT/pages/core/beans.adoc +++ b/framework-docs/modules/ROOT/pages/core/beans.adoc @@ -84,7 +84,7 @@ created and initialized, you have a fully configured and executable system or application. .The Spring IoC container -image::images/container-magic.png[] +image::container-magic.png[] @@ -2727,7 +2727,7 @@ defined by that bean definition. This single instance is stored in a cache of su singleton beans, and all subsequent requests and references for that named bean return the cached object. The following image shows how the singleton scope works: -image::images/singleton.png[] +image::singleton.png[] Spring's concept of a singleton bean differs from the singleton pattern as defined in the Gang of Four (GoF) patterns book. The GoF singleton hard-codes the scope of an @@ -2760,7 +2760,7 @@ singleton scope for stateless beans. The following diagram illustrates the Spring prototype scope: -image::images/prototype.png[] +image::prototype.png[] (A data access object (DAO) is not typically configured as a prototype, because a typical DAO does not hold diff --git a/framework-docs/modules/ROOT/pages/data-access.adoc b/framework-docs/modules/ROOT/pages/data-access.adoc index c223788e6d..13fb9a2034 100644 --- a/framework-docs/modules/ROOT/pages/data-access.adoc +++ b/framework-docs/modules/ROOT/pages/data-access.adoc @@ -607,7 +607,7 @@ operations need to execute within the same Reactor context in the same reactive The following image shows a conceptual view of calling a method on a transactional proxy: -image::images/tx.png[] +image::tx.png[] [[transaction-declarative-first-example]] @@ -1967,7 +1967,7 @@ logical transactions, and how the propagation setting applies to this difference [[tx-propagation-required]] ===== Understanding `PROPAGATION_REQUIRED` -image::images/tx_prop_required.png[] +image::tx_prop_required.png[] `PROPAGATION_REQUIRED` enforces a physical transaction, either locally for the current scope if no transaction exists yet or participating in an existing 'outer' transaction @@ -2004,7 +2004,7 @@ indicate clearly that a rollback was performed instead. [[tx-propagation-requires_new]] ===== Understanding `PROPAGATION_REQUIRES_NEW` -image::images/tx_prop_requires_new.png[] +image::tx_prop_requires_new.png[] `PROPAGATION_REQUIRES_NEW`, in contrast to `PROPAGATION_REQUIRED`, always uses an independent physical transaction for each affected transaction scope, never @@ -2955,7 +2955,7 @@ The following image shows the exception hierarchy that Spring provides. (Note that the class hierarchy detailed in the image shows only a subset of the entire `DataAccessException` hierarchy.) -image::images/DataAccessException.png[] +image::DataAccessException.png[] @@ -8736,7 +8736,7 @@ underlying O-X mapping tool does not do so. The O-X Mapping exception hierarchy is shown in the following figure: -image::images/oxm-exceptions.png[] +image::oxm-exceptions.png[] diff --git a/framework-docs/modules/ROOT/pages/web/webflux.adoc b/framework-docs/modules/ROOT/pages/web/webflux.adoc index 8f771502e3..a50f9f08e1 100644 --- a/framework-docs/modules/ROOT/pages/web/webflux.adoc +++ b/framework-docs/modules/ROOT/pages/web/webflux.adoc @@ -140,7 +140,7 @@ continuity and consistency with each other, they are available side by side, and from each side benefits both sides. The following diagram shows how the two relate, what they have in common, and what each supports uniquely: -image::images/spring-mvc-and-webflux-venn.png[] +image::spring-mvc-and-webflux-venn.png[] We suggest that you consider the following specific points: diff --git a/framework-docs/modules/ROOT/pages/web/webmvc.adoc b/framework-docs/modules/ROOT/pages/web/webmvc.adoc index 9f732da708..6df553ffb9 100644 --- a/framework-docs/modules/ROOT/pages/web/webmvc.adoc +++ b/framework-docs/modules/ROOT/pages/web/webmvc.adoc @@ -154,7 +154,7 @@ are effectively inherited and can be overridden (that is, re-declared) in the Se child `WebApplicationContext`, which typically contains beans local to the given `Servlet`. The following image shows this relationship: -image::images/mvc-context-hierarchy.png[] +image::mvc-context-hierarchy.png[] The following example configures a `WebApplicationContext` hierarchy: diff --git a/framework-docs/modules/ROOT/pages/web/websocket.adoc b/framework-docs/modules/ROOT/pages/web/websocket.adoc index 94196410da..d584e03fb6 100644 --- a/framework-docs/modules/ROOT/pages/web/websocket.adoc +++ b/framework-docs/modules/ROOT/pages/web/websocket.adoc @@ -1114,7 +1114,7 @@ Both the Java configuration (that is, `@EnableWebSocketMessageBroker`) and the X workflow. The following diagram shows the components used when the simple built-in message broker is enabled: -image::images/message-flow-simple-broker.png[] +image::message-flow-simple-broker.png[] The preceding diagram shows three message channels: @@ -1126,7 +1126,7 @@ server-side application code. The next diagram shows the components used when an external broker (such as RabbitMQ) is configured for managing subscriptions and broadcasting messages: -image::images/message-flow-broker-relay.png[] +image::message-flow-broker-relay.png[] The main difference between the two preceding diagrams is the use of the "`broker relay`" for passing messages up to the external STOMP broker over TCP and for passing messages down from the