Fix image::image

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

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

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[]
 
 
 

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:
 

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:
 

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