Fix image::image
This commit is contained in:
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
|
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:
|
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"]
|
[source,java,indent=0,subs="verbatim",role="primary"]
|
||||||
.Java
|
.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
|
Things change slightly when the reference that client code has is a proxy. Consider the
|
||||||
following diagram and code snippet:
|
following diagram and code snippet:
|
||||||
|
|
||||||
image::images/aop-proxy-call.png[]
|
image::aop-proxy-call.png[]
|
||||||
|
|
||||||
[source,java,indent=0,subs="verbatim",role="primary"]
|
[source,java,indent=0,subs="verbatim",role="primary"]
|
||||||
.Java
|
.Java
|
||||||
|
|
|
||||||
|
|
@ -84,7 +84,7 @@ created and initialized, you have a fully configured and executable system or
|
||||||
application.
|
application.
|
||||||
|
|
||||||
.The Spring IoC container
|
.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
|
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:
|
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
|
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
|
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:
|
The following diagram illustrates the Spring prototype scope:
|
||||||
|
|
||||||
image::images/prototype.png[]
|
image::prototype.png[]
|
||||||
|
|
||||||
(A data access object
|
(A data access object
|
||||||
(DAO) is not typically configured as a prototype, because a typical DAO does not hold
|
(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:
|
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]]
|
[[transaction-declarative-first-example]]
|
||||||
|
|
@ -1967,7 +1967,7 @@ logical transactions, and how the propagation setting applies to this difference
|
||||||
[[tx-propagation-required]]
|
[[tx-propagation-required]]
|
||||||
===== Understanding `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
|
`PROPAGATION_REQUIRED` enforces a physical transaction, either locally for the current
|
||||||
scope if no transaction exists yet or participating in an existing 'outer' transaction
|
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]]
|
[[tx-propagation-requires_new]]
|
||||||
===== Understanding `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
|
`PROPAGATION_REQUIRES_NEW`, in contrast to `PROPAGATION_REQUIRED`, always uses an
|
||||||
independent physical transaction for each affected transaction scope, never
|
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
|
(Note that the class hierarchy detailed in the image shows only a subset of the entire
|
||||||
`DataAccessException` hierarchy.)
|
`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:
|
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
|
from each side benefits both sides. The following diagram shows how the two relate, what they
|
||||||
have in common, and what each supports uniquely:
|
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:
|
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`.
|
child `WebApplicationContext`, which typically contains beans local to the given `Servlet`.
|
||||||
The following image shows this relationship:
|
The following image shows this relationship:
|
||||||
|
|
||||||
image::images/mvc-context-hierarchy.png[]
|
image::mvc-context-hierarchy.png[]
|
||||||
|
|
||||||
The following example configures a `WebApplicationContext` hierarchy:
|
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
|
workflow. The following diagram shows the components used when the simple built-in message
|
||||||
broker is enabled:
|
broker is enabled:
|
||||||
|
|
||||||
image::images/message-flow-simple-broker.png[]
|
image::message-flow-simple-broker.png[]
|
||||||
|
|
||||||
The preceding diagram shows three message channels:
|
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)
|
The next diagram shows the components used when an external broker (such as RabbitMQ)
|
||||||
is configured for managing subscriptions and broadcasting messages:
|
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
|
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
|
messages up to the external STOMP broker over TCP and for passing messages down from the
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue