diff --git a/framework-docs/modules/ROOT/pages/core/aop.adoc b/framework-docs/modules/ROOT/pages/core/aop.adoc index 2ab57095200..be7e6b7d963 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 3afd9096552..064d8376332 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 c223788e6d0..13fb9a20340 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 8f771502e36..a50f9f08e1f 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 9f732da708e..6df553ffb97 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 94196410daf..d584e03fb61 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