Trim IDs with parent
This commit is contained in:
Rob Winch
rstoyanchev
parent
9c38f8c3c6
commit
3774e9be7a
|
|
@ -48,7 +48,7 @@ element, as the following example shows:
|
|||
|
||||
This assumes that you use schema support as described in
|
||||
xref:core/appendix/xsd-schemas.adoc[XML Schema-based configuration].
|
||||
See xref:core/appendix/xsd-schemas.adoc#core.appendix.xsd-schemas-aop[the AOP schema] for how to
|
||||
See xref:core/appendix/xsd-schemas.adoc#aop[the AOP schema] for how to
|
||||
import the tags in the `aop` namespace.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ of advice parameters.
|
|||
|
||||
To use the aop namespace tags described in this section, you need to import the
|
||||
`spring-aop` schema, as described in xref:core/appendix/xsd-schemas.adoc[XML Schema-based configuration]
|
||||
. See xref:core/appendix/xsd-schemas.adoc#core.appendix.xsd-schemas-aop[the AOP schema]
|
||||
. See xref:core/appendix/xsd-schemas.adoc#aop[the AOP schema]
|
||||
for how to import the tags in the `aop` namespace.
|
||||
|
||||
Within your Spring configurations, all aspect and advisor elements must be placed within
|
||||
|
|
|
|||
|
|
@ -182,7 +182,7 @@ use Java-based configuration, you can add `@EnableSpringConfigured` to any
|
|||
----
|
||||
|
||||
If you prefer XML based configuration, the Spring
|
||||
xref:core/appendix/xsd-schemas.adoc#core.appendix.xsd-schemas-context[`context` namespace]
|
||||
xref:core/appendix/xsd-schemas.adoc#context[`context` namespace]
|
||||
defines a convenient `context:spring-configured` element, which you can use as follows:
|
||||
|
||||
[source,xml,indent=0,subs="verbatim"]
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
[[core.aot]]
|
||||
[[aot]]
|
||||
= Ahead of Time Optimizations
|
||||
|
||||
This chapter covers Spring's Ahead of Time (AOT) optimizations.
|
||||
|
||||
For AOT support specific to integration tests, see xref:testing/testcontext-framework/aot.adoc[Ahead of Time Support for Tests].
|
||||
|
||||
[[core.aot.introduction]]
|
||||
[[aot.introduction]]
|
||||
== Introduction to Ahead of Time Optimizations
|
||||
|
||||
Spring's support for AOT optimizations is meant to inspect an `ApplicationContext` at build time and apply decisions and discovery logic that usually happens at runtime.
|
||||
|
|
@ -30,7 +30,7 @@ A Spring AOT processed application typically generates:
|
|||
NOTE: At the moment, AOT is focused on allowing Spring applications to be deployed as native images using GraalVM.
|
||||
We intend to support more JVM-based use cases in future generations.
|
||||
|
||||
[[core.aot.basics]]
|
||||
[[aot.basics]]
|
||||
== AOT engine overview
|
||||
|
||||
The entry point of the AOT engine for processing an `ApplicationContext` arrangement is `ApplicationContextAotGenerator`. It takes care of the following steps, based on a `GenericApplicationContext` that represents the application to optimize and a {api-spring-framework}/aot/generate/GenerationContext.html[`GenerationContext`]:
|
||||
|
|
@ -46,7 +46,7 @@ The `RuntimeHints` instance can also be used to generate the relevant GraalVM na
|
|||
|
||||
Those steps are covered in greater detail in the sections below.
|
||||
|
||||
[[core.aot.refresh]]
|
||||
[[aot.refresh]]
|
||||
== Refresh for AOT Processing
|
||||
|
||||
Refresh for AOT processing is supported on all `GenericApplicationContext` implementations.
|
||||
|
|
@ -54,13 +54,13 @@ An application context is created with any number of entry points, usually in th
|
|||
|
||||
Let's look at a basic example:
|
||||
|
||||
include-code::AotProcessingSample[tag=myapplication]
|
||||
include-code::./AotProcessingSample[tag=myapplication]
|
||||
|
||||
Starting this application with the regular runtime involves a number of steps including classpath scanning, configuration class parsing, bean instantiation, and lifecycle callback handling.
|
||||
Refresh for AOT processing only applies a subset of what happens with a xref:core/beans/introduction.adoc[regular `refresh`].
|
||||
AOT processing can be triggered as follows:
|
||||
|
||||
include-code::AotProcessingSample[tag=aotcontext]
|
||||
include-code::./AotProcessingSample[tag=aotcontext]
|
||||
|
||||
In this mode, xref:core/beans/factory-extension.adoc#beans-factory-extension-factory-postprocessors[`BeanFactoryPostProcessor` implementations] are invoked as usual.
|
||||
This includes configuration class parsing, import selectors, classpath scanning, etc.
|
||||
|
|
@ -76,7 +76,7 @@ This makes sure to create any proxy that will be required at runtime.
|
|||
|
||||
Once this part completes, the `BeanFactory` contains the bean definitions that are necessary for the application to run. It does not trigger bean instantiation but allows the AOT engine to inspect the beans that will be created at runtime.
|
||||
|
||||
[[core.aot.bean-factory-initialization-contributions]]
|
||||
[[aot.bean-factory-initialization-contributions]]
|
||||
== Bean Factory Initialization AOT Contributions
|
||||
|
||||
Components that want to participate in this step can implement the {api-spring-framework}/beans/factory/aot/BeanFactoryInitializationAotProcessor.html[`BeanFactoryInitializationAotProcessor`] interface.
|
||||
|
|
@ -99,7 +99,7 @@ If such a bean is registered using an `@Bean` factory method, ensure the method
|
|||
====
|
||||
|
||||
|
||||
[[core.aot.bean-registration-contributions]]
|
||||
[[aot.bean-registration-contributions]]
|
||||
=== Bean Registration AOT Contributions
|
||||
|
||||
A core `BeanFactoryInitializationAotProcessor` implementation is responsible for collecting the necessary contributions for each candidate `BeanDefinition`.
|
||||
|
|
@ -186,7 +186,7 @@ When a `datasource` instance is required, a `BeanInstanceSupplier` is called.
|
|||
This supplier invokes the `dataSource()` method on the `dataSourceConfiguration` bean.
|
||||
|
||||
|
||||
[[core.aot.hints]]
|
||||
[[aot.hints]]
|
||||
== Runtime Hints
|
||||
|
||||
Running an application as a native image requires additional information compared to a regular JVM runtime.
|
||||
|
|
@ -210,14 +210,14 @@ For cases that the core container cannot infer, you can register such hints prog
|
|||
A number of convenient annotations are also provided for common use cases.
|
||||
|
||||
|
||||
[[core.aot.hints.import-runtime-hints]]
|
||||
[[aot.hints.import-runtime-hints]]
|
||||
=== `@ImportRuntimeHints`
|
||||
|
||||
`RuntimeHintsRegistrar` implementations allow you to get a callback to the `RuntimeHints` instance managed by the AOT engine.
|
||||
Implementations of this interface can be registered using `@ImportRuntimeHints` on any Spring bean or `@Bean` factory method.
|
||||
`RuntimeHintsRegistrar` implementations are detected and invoked at build time.
|
||||
|
||||
include-code::SpellCheckService[]
|
||||
include-code::./SpellCheckService[]
|
||||
|
||||
If at all possible, `@ImportRuntimeHints` should be used as close as possible to the component that requires the hints.
|
||||
This way, if the component is not contributed to the `BeanFactory`, the hints won't be contributed either.
|
||||
|
|
@ -225,7 +225,7 @@ This way, if the component is not contributed to the `BeanFactory`, the hints wo
|
|||
It is also possible to register an implementation statically by adding an entry in `META-INF/spring/aot.factories` with a key equal to the fully qualified name of the `RuntimeHintsRegistrar` interface.
|
||||
|
||||
|
||||
[[core.aot.hints.reflective]]
|
||||
[[aot.hints.reflective]]
|
||||
=== `@Reflective`
|
||||
|
||||
{api-spring-framework}/aot/hint/annotation/Reflective.html[`@Reflective`] provides an idiomatic way to flag the need for reflection on an annotated element.
|
||||
|
|
@ -239,7 +239,7 @@ Library authors can reuse this annotation for their own purposes.
|
|||
If components other than Spring beans need to be processed, a `BeanFactoryInitializationAotProcessor` can detect the relevant types and use `ReflectiveRuntimeHintsRegistrar` to process them.
|
||||
|
||||
|
||||
[[core.aot.hints.register-reflection-for-binding]]
|
||||
[[aot.hints.register-reflection-for-binding]]
|
||||
=== `@RegisterReflectionForBinding`
|
||||
|
||||
{api-spring-framework}/aot/hint/annotation/RegisterReflectionForBinding.html[`@RegisterReflectionForBinding`] is a specialization of `@Reflective` that registers the need for serializing arbitrary types.
|
||||
|
|
@ -262,14 +262,14 @@ The following example registers `Account` for serialization.
|
|||
}
|
||||
----
|
||||
|
||||
[[core.aot.hints.testing]]
|
||||
[[aot.hints.testing]]
|
||||
=== Testing Runtime Hints
|
||||
|
||||
Spring Core also ships `RuntimeHintsPredicates`, a utility for checking that existing hints match a particular use case.
|
||||
This can be used in your own tests to validate that a `RuntimeHintsRegistrar` contains the expected results.
|
||||
We can write a test for our `SpellCheckService` and ensure that we will be able to load a dictionary at runtime:
|
||||
|
||||
include-code::SpellCheckServiceTests[tag=hintspredicates]
|
||||
include-code::./SpellCheckServiceTests[tag=hintspredicates]
|
||||
|
||||
With `RuntimeHintsPredicates`, we can check for reflection, resource, serialization, or proxy generation hints.
|
||||
This approach works well for unit tests but implies that the runtime behavior of a component is well known.
|
||||
|
|
@ -281,11 +281,11 @@ For more targeted discovery and testing, Spring Framework ships a dedicated modu
|
|||
This module contains the RuntimeHints Agent, a Java agent that records all method invocations that are related to runtime hints and helps you to assert that a given `RuntimeHints` instance covers all recorded invocations.
|
||||
Let's consider a piece of infrastructure for which we'd like to test the hints we're contributing during the AOT processing phase.
|
||||
|
||||
include-code::SampleReflection[]
|
||||
include-code::./SampleReflection[]
|
||||
|
||||
We can then write a unit test (no native compilation required) that checks our contributed hints:
|
||||
|
||||
include-code::SampleReflectionRuntimeHintsTests[]
|
||||
include-code::./SampleReflectionRuntimeHintsTests[]
|
||||
|
||||
If you forgot to contribute a hint, the test will fail and provide some details about the invocation:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
[[core.appendix]]
|
||||
[[appendix]]
|
||||
= Appendix
|
||||
:page-section-summary-toc: 1
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
[[core.appendix.application-startup-steps]]
|
||||
[[application-startup-steps]]
|
||||
= Application Startup Steps
|
||||
|
||||
This part of the appendix lists the existing `StartupSteps` that the core container is instrumented with.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
[[core.appendix.xml-custom]]
|
||||
[[xml-custom]]
|
||||
= XML Schema Authoring
|
||||
|
||||
[[core.appendix.xsd-custom-introduction]]
|
||||
[[xsd-custom-introduction]]
|
||||
Since version 2.0, Spring has featured a mechanism for adding schema-based extensions to the
|
||||
basic Spring XML format for defining and configuring beans. This section covers
|
||||
how to write your own custom XML bean definition parsers and
|
||||
|
|
@ -39,7 +39,7 @@ through the basic steps of making a custom extension.)
|
|||
|
||||
|
||||
|
||||
[[core.appendix.xsd-custom-schema]]
|
||||
[[xsd-custom-schema]]
|
||||
== Authoring the Schema
|
||||
|
||||
Creating an XML configuration extension for use with Spring's IoC container starts with
|
||||
|
|
@ -111,7 +111,7 @@ defined in the enumeration.
|
|||
|
||||
|
||||
|
||||
[[core.appendix.xsd-custom-namespacehandler]]
|
||||
[[xsd-custom-namespacehandler]]
|
||||
== Coding a `NamespaceHandler`
|
||||
|
||||
In addition to the schema, we need a `NamespaceHandler` to parse all elements of
|
||||
|
|
@ -182,7 +182,7 @@ custom element, as we can see in the next step.
|
|||
|
||||
|
||||
|
||||
[[core.appendix.xsd-custom-parser]]
|
||||
[[xsd-custom-parser]]
|
||||
== Using `BeanDefinitionParser`
|
||||
|
||||
A `BeanDefinitionParser` is used if the `NamespaceHandler` encounters an XML
|
||||
|
|
@ -272,7 +272,7 @@ is the extraction and setting of the bean definition's unique identifier.
|
|||
|
||||
|
||||
|
||||
[[core.appendix.xsd-custom-registration]]
|
||||
[[xsd-custom-registration]]
|
||||
== Registering the Handler and the Schema
|
||||
|
||||
The coding is finished. All that remains to be done is to make the Spring XML
|
||||
|
|
@ -284,7 +284,7 @@ XML parsing infrastructure automatically picks up your new extension by consumin
|
|||
these special properties files, the formats of which are detailed in the next two sections.
|
||||
|
||||
|
||||
[[core.appendix.xsd-custom-registration-spring-handlers]]
|
||||
[[xsd-custom-registration-spring-handlers]]
|
||||
=== Writing `META-INF/spring.handlers`
|
||||
|
||||
The properties file called `spring.handlers` contains a mapping of XML Schema URIs to
|
||||
|
|
@ -303,7 +303,7 @@ namespace extension and needs to exactly match exactly the value of the `targetN
|
|||
attribute, as specified in your custom XSD schema.
|
||||
|
||||
|
||||
[[core.appendix.xsd-custom-registration-spring-schemas]]
|
||||
[[xsd-custom-registration-spring-schemas]]
|
||||
=== Writing 'META-INF/spring.schemas'
|
||||
|
||||
The properties file called `spring.schemas` contains a mapping of XML Schema locations
|
||||
|
|
@ -327,7 +327,7 @@ the `NamespaceHandler` and `BeanDefinitionParser` classes on the classpath.
|
|||
|
||||
|
||||
|
||||
[[core.appendix.xsd-custom-using]]
|
||||
[[xsd-custom-using]]
|
||||
== Using a Custom Extension in Your Spring XML Configuration
|
||||
|
||||
Using a custom extension that you yourself have implemented is no different from using
|
||||
|
|
@ -361,13 +361,13 @@ in a Spring XML configuration file:
|
|||
|
||||
|
||||
|
||||
[[core.appendix.xsd-custom-meat]]
|
||||
[[xsd-custom-meat]]
|
||||
== More Detailed Examples
|
||||
|
||||
This section presents some more detailed examples of custom XML extensions.
|
||||
|
||||
|
||||
[[core.appendix.xsd-custom-custom-nested]]
|
||||
[[xsd-custom-custom-nested]]
|
||||
=== Nesting Custom Elements within Custom Elements
|
||||
|
||||
The example presented in this section shows how you to write the various artifacts required
|
||||
|
|
@ -719,7 +719,7 @@ http\://www.foo.example/schema/component/component.xsd=com/foo/component.xsd
|
|||
----
|
||||
|
||||
|
||||
[[core.appendix.xsd-custom-custom-just-attributes]]
|
||||
[[xsd-custom-custom-just-attributes]]
|
||||
=== Custom Attributes on "`Normal`" Elements
|
||||
|
||||
Writing your own custom parser and the associated artifacts is not hard. However,
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
[[core.appendix.xsd-schemas]]
|
||||
[[xsd-schemas]]
|
||||
= XML Schemas
|
||||
|
||||
This part of the appendix lists XML schemas related to the core container.
|
||||
|
||||
|
||||
|
||||
[[core.appendix.xsd-schemas-util]]
|
||||
[[xsd-schemas-util]]
|
||||
== The `util` Schema
|
||||
|
||||
As the name implies, the `util` tags deal with common, utility configuration
|
||||
|
|
@ -30,7 +30,7 @@ correct schema so that the tags in the `util` namespace are available to you):
|
|||
----
|
||||
|
||||
|
||||
[[core.appendix.xsd-schemas-util-constant]]
|
||||
[[xsd-schemas-util-constant]]
|
||||
=== Using `<util:constant/>`
|
||||
|
||||
Consider the following bean definition:
|
||||
|
|
@ -63,7 +63,7 @@ developer's intent ("`inject this constant value`"), and it reads better:
|
|||
</bean>
|
||||
----
|
||||
|
||||
[[core.appendix.xsd-schemas-util-frfb]]
|
||||
[[xsd-schemas-util-frfb]]
|
||||
==== Setting a Bean Property or Constructor Argument from a Field Value
|
||||
|
||||
{api-spring-framework}/beans/factory/config/FieldRetrievingFactoryBean.html[`FieldRetrievingFactoryBean`]
|
||||
|
|
@ -175,7 +175,7 @@ Now consider the following setter of type `PersistenceContextType` and the corre
|
|||
----
|
||||
|
||||
|
||||
[[core.appendix.xsd-schemas-util-property-path]]
|
||||
[[xsd-schemas-util-property-path]]
|
||||
=== Using `<util:property-path/>`
|
||||
|
||||
Consider the following example:
|
||||
|
|
@ -222,7 +222,7 @@ The value of the `path` attribute of the `<property-path/>` element follows the
|
|||
`beanName.beanProperty`. In this case, it picks up the `age` property of the bean named
|
||||
`testBean`. The value of that `age` property is `10`.
|
||||
|
||||
[[core.appendix.xsd-schemas-util-property-path-dependency]]
|
||||
[[xsd-schemas-util-property-path-dependency]]
|
||||
==== Using `<util:property-path/>` to Set a Bean Property or Constructor Argument
|
||||
|
||||
`PropertyPathFactoryBean` is a `FactoryBean` that evaluates a property path on a given
|
||||
|
|
@ -297,7 +297,7 @@ for most use cases, but it can sometimes be useful. See the javadoc for more inf
|
|||
this feature.
|
||||
|
||||
|
||||
[[core.appendix.xsd-schemas-util-properties]]
|
||||
[[xsd-schemas-util-properties]]
|
||||
=== Using `<util:properties/>`
|
||||
|
||||
Consider the following example:
|
||||
|
|
@ -323,7 +323,7 @@ The following example uses a `util:properties` element to make a more concise re
|
|||
----
|
||||
|
||||
|
||||
[[core.appendix.xsd-schemas-util-list]]
|
||||
[[xsd-schemas-util-list]]
|
||||
=== Using `<util:list/>`
|
||||
|
||||
Consider the following example:
|
||||
|
|
@ -378,7 +378,7 @@ following configuration:
|
|||
If no `list-class` attribute is supplied, the container chooses a `List` implementation.
|
||||
|
||||
|
||||
[[core.appendix.xsd-schemas-util-map]]
|
||||
[[xsd-schemas-util-map]]
|
||||
=== Using `<util:map/>`
|
||||
|
||||
Consider the following example:
|
||||
|
|
@ -433,7 +433,7 @@ following configuration:
|
|||
If no `'map-class'` attribute is supplied, the container chooses a `Map` implementation.
|
||||
|
||||
|
||||
[[core.appendix.xsd-schemas-util-set]]
|
||||
[[xsd-schemas-util-set]]
|
||||
=== Using `<util:set/>`
|
||||
|
||||
Consider the following example:
|
||||
|
|
@ -489,7 +489,7 @@ If no `set-class` attribute is supplied, the container chooses a `Set` implement
|
|||
|
||||
|
||||
|
||||
[[core.appendix.xsd-schemas-aop]]
|
||||
[[xsd-schemas-aop]]
|
||||
== The `aop` Schema
|
||||
|
||||
The `aop` tags deal with configuring all things AOP in Spring, including Spring's
|
||||
|
|
@ -519,7 +519,7 @@ are available to you):
|
|||
|
||||
|
||||
|
||||
[[core.appendix.xsd-schemas-context]]
|
||||
[[xsd-schemas-context]]
|
||||
== The `context` Schema
|
||||
|
||||
The `context` tags deal with `ApplicationContext` configuration that relates to plumbing
|
||||
|
|
@ -544,7 +544,7 @@ available to you:
|
|||
----
|
||||
|
||||
|
||||
[[core.appendix.xsd-schemas-context-pphc]]
|
||||
[[xsd-schemas-context-pphc]]
|
||||
=== Using `<property-placeholder/>`
|
||||
|
||||
This element activates the replacement of `${...}` placeholders, which are resolved against a
|
||||
|
|
@ -554,7 +554,7 @@ is a convenience mechanism that sets up a xref:core/beans/factory-extension.adoc
|
|||
`PropertySourcesPlaceholderConfigurer` setup, you can explicitly define it as a bean yourself.
|
||||
|
||||
|
||||
[[core.appendix.xsd-schemas-context-ac]]
|
||||
[[xsd-schemas-context-ac]]
|
||||
=== Using `<annotation-config/>`
|
||||
|
||||
This element activates the Spring infrastructure to detect annotations in bean classes:
|
||||
|
|
@ -577,28 +577,28 @@ xref:integration/cache/annotations.adoc[caching annotations] need to be explicit
|
|||
xref:integration/cache/annotations.adoc#cache-annotation-enable[enabled] as well.
|
||||
|
||||
|
||||
[[core.appendix.xsd-schemas-context-component-scan]]
|
||||
[[xsd-schemas-context-component-scan]]
|
||||
=== Using `<component-scan/>`
|
||||
|
||||
This element is detailed in the section on xref:core/beans/annotation-config.adoc[annotation-based container configuration]
|
||||
.
|
||||
|
||||
|
||||
[[core.appendix.xsd-schemas-context-ltw]]
|
||||
[[xsd-schemas-context-ltw]]
|
||||
=== Using `<load-time-weaver/>`
|
||||
|
||||
This element is detailed in the section on xref:core/aop/using-aspectj.adoc#aop-aj-ltw[load-time weaving with AspectJ in the Spring Framework]
|
||||
.
|
||||
|
||||
|
||||
[[core.appendix.xsd-schemas-context-sc]]
|
||||
[[xsd-schemas-context-sc]]
|
||||
=== Using `<spring-configured/>`
|
||||
|
||||
This element is detailed in the section on xref:core/aop/using-aspectj.adoc#aop-atconfigurable[using AspectJ to dependency inject domain objects with Spring]
|
||||
.
|
||||
|
||||
|
||||
[[core.appendix.xsd-schemas-context-mbe]]
|
||||
[[xsd-schemas-context-mbe]]
|
||||
=== Using `<mbean-export/>`
|
||||
|
||||
This element is detailed in the section on xref:integration/jmx/naming.adoc#jmx-context-mbeanexport[configuring annotation-based MBean export]
|
||||
|
|
@ -606,7 +606,7 @@ This element is detailed in the section on xref:integration/jmx/naming.adoc#jmx-
|
|||
|
||||
|
||||
|
||||
[[core.appendix.xsd-schemas-beans]]
|
||||
[[xsd-schemas-beans]]
|
||||
== The Beans Schema
|
||||
|
||||
Last but not least, we have the elements in the `beans` schema. These elements
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
[[data.access.appendix]]
|
||||
[[appendix]]
|
||||
= Appendix
|
||||
|
||||
|
||||
|
||||
|
||||
[[data.access.xsd-schemas]]
|
||||
[[xsd-schemas]]
|
||||
== XML Schemas
|
||||
|
||||
This part of the appendix lists XML schemas for data access, including the following:
|
||||
|
|
|
|||
|
|
@ -179,7 +179,7 @@ infrastructure.
|
|||
|
||||
NOTE: The preceding definition of the `dataSource` bean uses the `<jndi-lookup/>` tag
|
||||
from the `jee` namespace. For more information see
|
||||
xref:integration/appendix.adoc#integration.appendix.xsd-schemas-jee[The JEE Schema].
|
||||
xref:integration/appendix.adoc#xsd-schemas-jee[The JEE Schema].
|
||||
|
||||
NOTE: If you use JTA, your transaction manager definition should look the same, regardless
|
||||
of what data access technology you use, be it JDBC, Hibernate JPA, or any other supported
|
||||
|
|
|
|||
|
|
@ -1,17 +1,17 @@
|
|||
[[integration.appendix]]
|
||||
[[appendix]]
|
||||
= Appendix
|
||||
|
||||
|
||||
|
||||
|
||||
[[integration.appendix.xsd-schemas]]
|
||||
[[appendix.xsd-schemas]]
|
||||
== XML Schemas
|
||||
|
||||
This part of the appendix lists XML schemas related to integration technologies.
|
||||
|
||||
|
||||
|
||||
[[integration.appendix.xsd-schemas-jee]]
|
||||
[[appendix.xsd-schemas-jee]]
|
||||
=== The `jee` Schema
|
||||
|
||||
The `jee` elements deal with issues related to Jakarta EE (Enterprise Edition) configuration,
|
||||
|
|
@ -40,7 +40,7 @@ correct schema so that the elements in the `jee` namespace are available to you:
|
|||
|
||||
|
||||
|
||||
[[integration.appendix.xsd-schemas-jee-jndi-lookup]]
|
||||
[[appendix.xsd-schemas-jee-jndi-lookup]]
|
||||
==== <jee:jndi-lookup/> (simple)
|
||||
|
||||
The following example shows how to use JNDI to look up a data source without the `jee` schema:
|
||||
|
|
@ -71,7 +71,7 @@ schema:
|
|||
|
||||
|
||||
|
||||
[[integration.appendix.xsd-schemas-jee-jndi-lookup-environment-single]]
|
||||
[[appendix.xsd-schemas-jee-jndi-lookup-environment-single]]
|
||||
==== `<jee:jndi-lookup/>` (with Single JNDI Environment Setting)
|
||||
|
||||
The following example shows how to use JNDI to look up an environment variable without
|
||||
|
|
@ -99,7 +99,7 @@ The following example shows how to use JNDI to look up an environment variable w
|
|||
----
|
||||
|
||||
|
||||
[[integration.appendix.xsd-schemas-jee-jndi-lookup-environment-multiple]]
|
||||
[[appendix.xsd-schemas-jee-jndi-lookup-environment-multiple]]
|
||||
==== `<jee:jndi-lookup/>` (with Multiple JNDI Environment Settings)
|
||||
|
||||
The following example shows how to use JNDI to look up multiple environment variables
|
||||
|
|
@ -133,7 +133,7 @@ The following example shows how to use JNDI to look up multiple environment vari
|
|||
----
|
||||
|
||||
|
||||
[[integration.appendix.xsd-schemas-jee-jndi-lookup-complex]]
|
||||
[[appendix.xsd-schemas-jee-jndi-lookup-complex]]
|
||||
==== `<jee:jndi-lookup/>` (Complex)
|
||||
|
||||
The following example shows how to use JNDI to look up a data source and a number of
|
||||
|
|
@ -167,7 +167,7 @@ different properties with `jee`:
|
|||
|
||||
|
||||
|
||||
[[integration.appendix.xsd-schemas-jee-local-slsb]]
|
||||
[[appendix.xsd-schemas-jee-local-slsb]]
|
||||
==== `<jee:local-slsb/>` (Simple)
|
||||
|
||||
The `<jee:local-slsb/>` element configures a reference to a local EJB Stateless Session Bean.
|
||||
|
|
@ -195,7 +195,7 @@ with `jee`:
|
|||
|
||||
|
||||
|
||||
[[integration.appendix.xsd-schemas-jee-local-slsb-complex]]
|
||||
[[appendix.xsd-schemas-jee-local-slsb-complex]]
|
||||
==== `<jee:local-slsb/>` (Complex)
|
||||
|
||||
The `<jee:local-slsb/>` element configures a reference to a local EJB Stateless Session Bean.
|
||||
|
|
@ -229,7 +229,7 @@ and a number of properties with `jee`:
|
|||
----
|
||||
|
||||
|
||||
[[integration.appendix.xsd-schemas-jee-remote-slsb]]
|
||||
[[appendix.xsd-schemas-jee-remote-slsb]]
|
||||
==== <jee:remote-slsb/>
|
||||
|
||||
The `<jee:remote-slsb/>` element configures a reference to a `remote` EJB Stateless Session Bean.
|
||||
|
|
@ -268,7 +268,7 @@ with `jee`:
|
|||
|
||||
|
||||
|
||||
[[integration.appendix.xsd-schemas-jms]]
|
||||
[[appendix.xsd-schemas-jms]]
|
||||
=== The `jms` Schema
|
||||
|
||||
The `jms` elements deal with configuring JMS-related beans, such as Spring's
|
||||
|
|
@ -301,7 +301,7 @@ are available to you:
|
|||
|
||||
|
||||
|
||||
[[integration.appendix.xsd-schemas-context-mbe]]
|
||||
[[appendix.xsd-schemas-context-mbe]]
|
||||
=== Using `<context:mbean-export/>`
|
||||
|
||||
This element is detailed in
|
||||
|
|
@ -309,7 +309,7 @@ xref:integration/jmx/naming.adoc#jmx-context-mbeanexport[Configuring Annotation-
|
|||
|
||||
|
||||
|
||||
[[integration.appendix.xsd-schemas-cache]]
|
||||
[[appendix.xsd-schemas-cache]]
|
||||
=== The `cache` Schema
|
||||
|
||||
You can use the `cache` elements to enable support for Spring's `@CacheEvict`, `@CachePut`,
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
[[integration.observability]]
|
||||
[[observability]]
|
||||
= Observability Support
|
||||
|
||||
Micrometer defines an https://micrometer.io/docs/observation[Observation concept that enables both Metrics and Traces] in applications.
|
||||
|
|
@ -10,7 +10,7 @@ Spring Framework instruments various parts of its own codebase to publish observ
|
|||
You can learn more about {docs-spring-boot}/html/actuator.html#actuator.metrics[configuring the observability infrastructure in Spring Boot].
|
||||
|
||||
|
||||
[[integration.observability.list]]
|
||||
[[observability.list]]
|
||||
== List of produced Observations
|
||||
|
||||
Spring Framework instruments various features for observability.
|
||||
|
|
@ -21,10 +21,10 @@ As outlined xref:integration/observability.adoc[at the beginning of this section
|
|||
|===
|
||||
|Observation name |Description
|
||||
|
||||
|xref:integration/observability.adoc#integration.observability.http-client[`"http.client.requests"`]
|
||||
|xref:integration/observability.adoc#http-client[`"http.client.requests"`]
|
||||
|Time spent for HTTP client exchanges
|
||||
|
||||
|xref:integration/observability.adoc#integration.observability.http-server[`"http.server.requests"`]
|
||||
|xref:integration/observability.adoc#http-server[`"http.server.requests"`]
|
||||
|Processing time for HTTP server exchanges at the Framework level
|
||||
|===
|
||||
|
||||
|
|
@ -33,7 +33,7 @@ https://micrometer.io/docs/concepts#_naming_meters[to the format preferred by th
|
|||
(Prometheus, Atlas, Graphite, InfluxDB...).
|
||||
|
||||
|
||||
[[integration.observability.concepts]]
|
||||
[[observability.concepts]]
|
||||
== Micrometer Observation concepts
|
||||
|
||||
If you are not familiar with Micrometer Observation, here's a quick summary of the new concepts you should know about.
|
||||
|
|
@ -49,7 +49,7 @@ If you are not familiar with Micrometer Observation, here's a quick summary of t
|
|||
* An `ObservationDocumentation` documents all observations in a particular domain, listing the expected key names and their meaning.
|
||||
|
||||
|
||||
[[integration.observability.config]]
|
||||
[[observability.config]]
|
||||
== Configuring Observations
|
||||
|
||||
Global configuration options are available at the `ObservationRegistry#observationConfig()` level.
|
||||
|
|
@ -59,33 +59,33 @@ Each instrumented component will provide two extension points:
|
|||
* providing a custom `ObservationConvention` to change the default observation name and extracted `KeyValues`
|
||||
|
||||
|
||||
[[integration.observability.config.conventions]]
|
||||
[[observability.config.conventions]]
|
||||
=== Using custom Observation conventions
|
||||
|
||||
Let's take the example of the Spring MVC "http.server.requests" metrics instrumentation with the `ServerHttpObservationFilter`.
|
||||
This observation is using a `ServerRequestObservationConvention` with a `ServerRequestObservationContext`; custom conventions can be configured on the Servlet filter.
|
||||
If you would like to customize the metadata produced with the observation, you can extend the `DefaultServerRequestObservationConvention` for your requirements:
|
||||
|
||||
include-code::ExtendedServerRequestObservationConvention[]
|
||||
include-code::./ExtendedServerRequestObservationConvention[]
|
||||
|
||||
If you want full control, you can then implement the entire convention contract for the observation you're interested in:
|
||||
|
||||
include-code::CustomServerRequestObservationConvention[]
|
||||
include-code::./CustomServerRequestObservationConvention[]
|
||||
|
||||
You can also achieve similar goals using a custom `ObservationFilter` - adding or removing key values for an observation.
|
||||
Filters do not replace the default convention and are used as a post-processing component.
|
||||
|
||||
include-code::ServerRequestObservationFilter[]
|
||||
include-code::./ServerRequestObservationFilter[]
|
||||
|
||||
You can configure `ObservationFilter` instances on the `ObservationRegistry`.
|
||||
|
||||
|
||||
[[integration.observability.http-server]]
|
||||
[[observability.http-server]]
|
||||
== HTTP Server instrumentation
|
||||
|
||||
HTTP server exchanges observations are created with the name `"http.server.requests"` for Servlet and Reactive applications.
|
||||
|
||||
[[integration.observability.http-server.servlet]]
|
||||
[[observability.http-server.servlet]]
|
||||
=== Servlet applications
|
||||
|
||||
Applications need to configure the `org.springframework.web.filter.ServerHttpObservationFilter` Servlet filter in their application.
|
||||
|
|
@ -95,7 +95,7 @@ This will only record an observation as an error if the `Exception` has not been
|
|||
Typically, all exceptions handled by Spring MVC's `@ExceptionHandler` and xref:web/webmvc/mvc-ann-rest-exceptions.adoc[`ProblemDetail` support] will not be recorded with the observation.
|
||||
You can, at any point during request processing, set the error field on the `ObservationContext` yourself:
|
||||
|
||||
include-code::UserController[]
|
||||
include-code::./UserController[]
|
||||
|
||||
By default, the following `KeyValues` are created:
|
||||
|
||||
|
|
@ -118,7 +118,7 @@ By default, the following `KeyValues` are created:
|
|||
|===
|
||||
|
||||
|
||||
[[integration.observability.http-server.reactive]]
|
||||
[[observability.http-server.reactive]]
|
||||
=== Reactive applications
|
||||
|
||||
Applications need to configure the `org.springframework.web.filter.reactive.ServerHttpObservationFilter` reactive `WebFilter` in their application.
|
||||
|
|
@ -128,7 +128,7 @@ This will only record an observation as an error if the `Exception` has not been
|
|||
Typically, all exceptions handled by Spring WebFlux's `@ExceptionHandler` and xref:web/webflux/ann-rest-exceptions.adoc[`ProblemDetail` support] will not be recorded with the observation.
|
||||
You can, at any point during request processing, set the error field on the `ObservationContext` yourself:
|
||||
|
||||
include-code::UserController[]
|
||||
include-code::./UserController[]
|
||||
|
||||
By default, the following `KeyValues` are created:
|
||||
|
||||
|
|
@ -152,13 +152,13 @@ By default, the following `KeyValues` are created:
|
|||
|
||||
|
||||
|
||||
[[integration.observability.http-client]]
|
||||
[[observability.http-client]]
|
||||
== HTTP Client instrumentation
|
||||
|
||||
HTTP client exchanges observations are created with the name `"http.client.requests"` for blocking and reactive clients.
|
||||
Unlike their server counterparts, the instrumentation is implemented directly in the client so the only required step is to configure an `ObservationRegistry` on the client.
|
||||
|
||||
[[integration.observability.http-client.resttemplate]]
|
||||
[[observability.http-client.resttemplate]]
|
||||
=== RestTemplate
|
||||
|
||||
Applications must configure an `ObservationRegistry` on `RestTemplate` instances to enable the instrumentation; without that, observations are "no-ops".
|
||||
|
|
@ -187,7 +187,7 @@ Instrumentation is using the `org.springframework.http.client.observation.Client
|
|||
|
||||
|
||||
|
||||
[[integration.observability.http-client.webclient]]
|
||||
[[observability.http-client.webclient]]
|
||||
=== WebClient
|
||||
|
||||
Applications must configure an `ObservationRegistry` on the `WebClient` builder to enable the instrumentation; without that, observations are "no-ops".
|
||||
|
|
|
|||
|
|
@ -118,7 +118,7 @@ accessing the status of a response that represents an error (such as 401). If th
|
|||
issue, switch to another HTTP client library.
|
||||
|
||||
NOTE: `RestTemplate` can be instrumented for observability, in order to produce metrics and traces.
|
||||
See the xref:integration/observability.adoc#integration.observability.http-client.resttemplate[RestTemplate Observability support] section.
|
||||
See the xref:integration/observability.adoc#http-client.resttemplate[RestTemplate Observability support] section.
|
||||
|
||||
[[rest-resttemplate-uri]]
|
||||
==== URIs
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
[[testing.appendix]]
|
||||
[[appendix]]
|
||||
= Appendix
|
||||
:page-section-summary-toc: 1
|
||||
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ following features.
|
|||
testing annotations -- as long as the tests are run using a JUnit Platform
|
||||
`TestEngine` that is registered for the current project.
|
||||
* Build-time AOT processing: each unique test `ApplicationContext` in the current project
|
||||
will be xref:core/aot.adoc#core.aot.refresh[refreshed for AOT processing].
|
||||
will be xref:core/aot.adoc#refresh[refreshed for AOT processing].
|
||||
* Runtime AOT support: when executing in AOT runtime mode, a Spring integration test will
|
||||
use an AOT-optimized `ApplicationContext` that participates transparently with the
|
||||
xref:testing/testcontext-framework/ctx-management/caching.adoc[context cache].
|
||||
|
|
@ -35,7 +35,7 @@ the following options.
|
|||
via {api-spring-framework}/context/annotation/ImportRuntimeHints.html[`@ImportRuntimeHints`].
|
||||
* Annotate a test class with {api-spring-framework}/aot/hint/annotation/Reflective.html[`@Reflective`] or
|
||||
{api-spring-framework}/aot/hint/annotation/RegisterReflectionForBinding.html[`@RegisterReflectionForBinding`].
|
||||
* See xref:core/aot.adoc#core.aot.hints[Runtime Hints] for details on Spring's core runtime hints
|
||||
* See xref:core/aot.adoc#hints[Runtime Hints] for details on Spring's core runtime hints
|
||||
and annotation support.
|
||||
|
||||
[TIP]
|
||||
|
|
|
|||
|
|
@ -16,8 +16,8 @@ You can also use `WebClient.builder()` with further options:
|
|||
* `filter`: Client filter for every request.
|
||||
* `exchangeStrategies`: HTTP message reader/writer customizations.
|
||||
* `clientConnector`: HTTP client library settings.
|
||||
* `observationRegistry`: the registry to use for enabling xref:integration/observability.adoc#integration.observability.http-client.webclient[Observability support].
|
||||
* `observationConvention`: xref:integration/observability.adoc#integration.observability.config[an optional, custom convention to extract metadata] for recorded observations.
|
||||
* `observationRegistry`: the registry to use for enabling xref:integration/observability.adoc#http-client.webclient[Observability support].
|
||||
* `observationConvention`: xref:integration/observability.adoc#config[an optional, custom convention to extract metadata] for recorded observations.
|
||||
|
||||
For example:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
[[webmvc.test]]
|
||||
[[test]]
|
||||
= Testing
|
||||
[.small]#xref:web-reactive.adoc#webflux-test[See equivalent in the Reactive stack]#
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue