Fix image::image
This commit is contained in:
Rob Winch
rstoyanchev
parent
a05ff6c126
commit
7f9061a3cb
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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[]
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Reference in New Issue