diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc
index 9cef9f6c74..73f5ebe2bd 100644
--- a/modules/ROOT/nav.adoc
+++ b/modules/ROOT/nav.adoc
@@ -49,12 +49,12 @@
   ** xref:distributed-session-caching.adoc[Distributed session caching]
   ** xref:configuring-infinispan-support.adoc[Configuring Infinispan as a JCache provider]
 * xref:observability.adoc[Observability]
-  ** xref:prepare-mptelemetry.adoc[Prepare your development environment for MicroProfile Telemetry]
+//  ** xref:prepare-mptelemetry.adoc[Prepare your development environment for MicroProfile Telemetry]
   ** xref:custom-mptelemetry-metrics.adoc[Define custom MicroProfile Telemetry metrics]
   ** xref:telemetry-trace.adoc[Code instrumentation for MicroProfile Telemetry tracing]
-  ** xref:mptelemetry-logging.adoc[Write logs with MicroProfile Telemetry logging]
-  ** xref:microservice-observability-metrics.adoc[Microservice observability with with MicroProfile Metrics]
-  ** xref:micrometer-metrics.adoc[Choose your own monitoring tools with MicroProfile Metrics]
+//  ** xref:mptelemetry-logging.adoc[Write logs with MicroProfile Telemetry logging]
+  ** xref:microservice-observability-metrics.adoc[Microservice observability with MicroProfile Metrics]
+    *** xref:micrometer-metrics.adoc[Choose your own monitoring tools with MicroProfile Metrics]
   ** xref:health-check-microservices.adoc[Health checks for microservices]
   ** https://openliberty.io/guides/#observability[Guides: Observability]
 * xref:integration-testing.adoc[Testing]
@@ -116,7 +116,6 @@
 
 // Begin operations section
 .Operations
-* xref:microprofile-telemetry.adoc[Enable observability with MicroProfile Telemetry]
 * xref:log-trace-configuration.adoc[Logs]
   ** xref:log-management.adoc[Log management]
   ** xref:access-logging.adoc[HTTP access logging]
@@ -132,6 +131,8 @@
   ** xref:metrics-list.adoc[MicroProfile Metrics reference list]
   ** xref:configuring-jmx-connection.adoc[Configuring JMX connections]
   ** xref:jmx-metrics-list.adoc[JMX metrics reference list]
+* xref:microprofile-telemetry.adoc[OpenTelemetry]
+  ** xref:telemetry-troubleshooting.adoc[Troubleshooting OpenTelemetry]
 * xref:slow-hung-request-detection.adoc[Slow and hung request detection]
 * xref:validating-server-connections.adoc[Validating server connections]
 * xref:admin-center.adoc[Admin Center GUI]
diff --git a/modules/ROOT/pages/custom-mptelemetry-metrics.adoc b/modules/ROOT/pages/custom-mptelemetry-metrics.adoc
index d92a5bbf35..38bd93de7b 100644
--- a/modules/ROOT/pages/custom-mptelemetry-metrics.adoc
+++ b/modules/ROOT/pages/custom-mptelemetry-metrics.adoc
@@ -14,11 +14,9 @@
 
 You can use the OpenTelemetry metrics API to define custom metrics in your application code. When you enable the MicroProfile Telemetry feature 2.0 or later, you can then collect and emit these metrics to customize the observability of your application.
 
-For more information about collecting and emitting metrics with MicroProfile Telemetry, see xref:microprofile-telemetry.adoc#metrics[Configuring Open Liberty to use MicroProfile Telemetry to collect metrics].
+For more information about collecting and emitting metrics with MicroProfile Telemetry, see xref:microprofile-telemetry.adoc[Collect logs, metrics, and traces with OpenTelemetry].
 
-For more information about OpenTelemetry metrics, see the link:https://www.javadoc.io/doc/io.opentelemetry/opentelemetry-api/1.39.0/io/opentelemetry/api/metrics/package-summary.html[OpenTelemetry metrics API documentation].
-
-Before you can use MicroProfile Telemetry to define custom metrics metrics, you must enable MicroProfile Telemetry in your development environment by editing your runtime configuration. You must also add the OpenTelemetry API and annotations as a dependency on your build path. For more information, see xref:prepare-mptelemetry.adoc[Prepare your development environment for MicroProfile Telemetry].
+Before you can use OpenTelemetry to define custom metrics metrics, you must make 3rd party APIs visible in your runtime environment by editing your runtime configuration. For more information, see link:/docs/latest/reference/feature/mpTelemetry-2.0.html#dev[Customize your application telemetry with the OpenTelemetry API].
 
 The following example defines a custom counter metric:
 
@@ -49,3 +47,5 @@ class WithCounter {
 In this example, `Meter` is used to define an instrument, in this case a Counter. Application code then can record measurement values along with other attributes. Measurement aggregations are computed separately for each unique combination of attributes.
 
 For a full list of available metrics, see link:https://opentelemetry.io/docs/specs/otel/metrics/api/#meter-operations[Meter operations] in the OpenTelemetry documentation.
+
+For more information about OpenTelemetry metrics, see the link:https://www.javadoc.io/doc/io.opentelemetry/opentelemetry-api/1.39.0/io/opentelemetry/api/metrics/package-summary.html[OpenTelemetry metrics API documentation].
diff --git a/modules/ROOT/pages/documentation-openapi.adoc b/modules/ROOT/pages/documentation-openapi.adoc
index f52b2829ec..d08fe0b6f3 100644
--- a/modules/ROOT/pages/documentation-openapi.adoc
+++ b/modules/ROOT/pages/documentation-openapi.adoc
@@ -15,7 +15,15 @@
 MicroProfile OpenAPI helps you to generate structured documentation from your Jakarta RESTful Services or JAX-RS applications. This documentation helps other microservices and developers to understand and communicate with your application.
 
 Other developers need relevant information to build an application that communicates with the REST API of your application.
-MicroProfile OpenAPI facilitates this communication by generating human and machine-readable documentation on a simple interface that doesn’t require access to the source code.
+MicroProfile OpenAPI facilitates this communication by generating human and machine-readable documentation on a simple interface that does not require access to the source code.
+
+The following sections provide more information about the available approaches, supported versions, and configurations for using MicroProfile OpenAPI with Open Liberty.
+
+* <<#code1, The code-first approach>>
+* <<#design1, The design-first approach>>
+* <<#supp-ver, Supported OpenAPI versions>>
+* <<#multi-module, Multiple application and multi-module application support>>
+
 
 You can implement MicroProfile OpenAPI for Open Liberty by enabling the feature:mpOpenAPI[display=MicroProfile OpenAPI] feature. When this feature is enabled, you can view the OpenAPI document in a browser by using the `/openapi` endpoint. For example, if your browser is on the same machine where your server is running, you can view the raw OpenAPI document at the `\http://localhost:9080/openapi` URL or view the OpenAPI document in a user interface at the `\http://localhost:9080/openapi/ui` URL.
 
@@ -29,6 +37,8 @@ The JAX-RS framework handles basic API generation for JAX-RS annotations and gen
 You can use this treemap as a starting point and augment it with annotations and code to produce a complete OpenAPI document.
 Additionally, you can use this manually created documentation to generate stubs, or testable versions of code modules, such as client libraries for the API.
 
+
+[#code1]
 == The code-first approach
 
 In the code-first approach, you can initially generate basic API documentation of the REST API from annotations that are specified in the source code.
@@ -112,12 +122,14 @@ The information that is provided through the OpenAPI annotations augments the ba
 
 For more information, see the link:reference/javadoc/microprofile-6.1-javadoc.html?package=org/eclipse/microprofile/openapi/package-frame.html&class=org/eclipse/microprofile/openapi/package-summary.html[MicroProfile OpenAPI Javadoc] for the available annotations.
 
+
+[#design1]
 == The design-first approach
 
-An alternative approach is to design the REST API in an editor, such as the link:https://editor.swagger.io/[Swagger] editor, before you write any code.
+An alternative approach is to design the REST API in an editor, such as the link:https://editor.swagger.io/[Swagger] editor before you write any code.
 With this approach, you can spot and rectify any issues in the design before it is implemented.
-In large companies, subject matter experts review the API to ensure it's consistent and usable.
-This API design then forms a contract and must be implemented as agreed.
+In large companies, subject matter experts review the API to ensure that it is consistent and usable.
+The API design then serves as a contract and must be implemented.
 
 You can write this API design in YAML or JSON format and place it in the `META-INF` directory of your application.
 Optionally, you can create stubs for the API code.
@@ -126,34 +138,139 @@ You can augment manually created API documents by adding annotations to the code
 
 For more information, see https://openliberty.io/guides/microprofile-openapi.html#using-pregenerated-openapi-documents[Using pregenerated OpenAPI documents].
 
+[#supp-ver]
+== Supported OpenAPI versions
+
+The MicroProfile OpenAPI feature generates structured documentation based on the OpenAPI specification. Each new version of the OpenAPI specification updates the documentation format, and different versions of MicroProfile OpenAPI support different OpenAPI specification versions.
+
+.Supported OpenAPI versions
+[cols="1,2", options="header"]
+|===
+|Feature | OpenAPI versions supported
+
+|`mpOpenAPI-4.0`
+| 3.1, 3.0
+
+|`mpOpenAPI-3.1` and earlier
+| 3.0
+|===
+
+If you are using a feature that supports more than one version of the OpenAPI specification, you can switch between versions with configuration. You might need to do this if you or your end users use tools or libraries that don't yet support a newer version of the OpenAPI specification.
+For more information, see link:/docs/latest/reference/feature/mpOpenAPI-4.0.html#apiversion[Selecting the OpenAPI specification version].
+
 
 [#multi-module]
 == Multiple application and multi-module application support with MicroProfile OpenAPI
 
-By default, OpenAPI documentation is generated for only the first web module of the first application that is deployed on the server. The MicroProfile OpenAPI feature, version 2.0 and later, provides configuration properties to select which applications and web modules OpenAPI documentation is generated for. If more than one web module or application is specified, an OpenAPI document is generated for each module or application and then they are merged to create a single OpenAPI document. A property is also provided to set the `info` section of the final merged OpenAPI document.
+When multiple applications or an application with more than one web module are deployed to the same Open Liberty runtime, the structured documentation differs depending on which MicroProfile OpenAPI feature version you use.
+
+.Multiple application and multi-module application support with MicroProfile OpenAPI
+[cols="1,2", options="header"]
+|===
+|Feature |Default behavior
+
+|`mpOpenAPI-4.0`
+|All deployed applications and modules are included in the structured documentation. You can modify this behavior through configuration.
+
+|`mpOpenAPI-2.0` to `mpOpenAPI-3.1`
+|Only the first web module of the first deployed application is included in the structured documentation. You can modify this behavior through configuration.
+
+|`mpOpenAPI-1.0` to `mpOpenAPI-1.1`
+|Only the first web module of the first deployed application is included in the structured documentation. This behavior cannot be modified.
+|===
+
+[#conf-mm-supprt]
+=== Including and excluding applications and modules from OpenAPI documentation
+
+You can configure which applications or modules are included in your OpenAPI documentation either by <<#server, setting elements in your `server.xml` file>> or by <<#mp-config, specifying MicroProfile Config properties>>. For most scenarios, `server.xml` configuration is preferred and MicroProfile Config properties are recommended only for compatibility with existing configurations that are already using these properties.
+
+[#server]
+==== Configure application or module documentation by using the `server.xml` file
+You can control the inclusion and exclusion of applications and modules in the OpenAPI documentation by configuring the following elements within the config:mpOpenAPI[] configuration element in your `server.xml` file:
+
+- `excludeModule` | `excludeApplication`: Specify module or application names, one per element, that are to be excluded from the OpenAPI document. Specify module names in the `{ApplicationName}/{ModuleName}` format.
+- `includeModule` | `includeApplication`: Specify module or application names, one per element, that are to be included in the OpenAPI document. Specify module names in the `{ApplicationName}/{ModuleName}` format. The `all` special value includes all available applications.
+- `info`: Specify an `info` section for the OpenAPI document. This element is useful to override the default `info` section of merged OpenAPI documentation for multiple modules or applications.
+
+In feature:mpOpenAPI-4.0[display=MicroProfile OpenAPI 4.0] and later, all applications and modules are included by default. To exclude certain applications or modules, specify the `excludeModule` or `excludeApplication` element within the `mpOpenAPI` element.
 
-For example, to include all the applications in your deployment in a single merged OpenAPI document, you can define the following MicroProfile Config property as a variable in your `server.xml` file.
+In the following example, the `sample_app` application consists of an EAR file containing five web modules. This configuration excludes modules 3 and 5 and provides a custom `info` section for the merged API documentation for modules 1, 2, and 4:
 
 [source,xml]
 ----
-<variable name="mp.openapi.extensions.liberty.merged.include" value="all"/>
+<mpOpenAPI>
+  <excludeModule>sample_app/module-3</excludeModule>
+  <excludeModule>sample_app/module-5</excludeModule>
+  <info title="A multi-module sample application"
+        description="This is a sample application."
+        version="2.0.1"
+        termsOfService="http://example.com/sample_app/terms"
+        contactName="API Support"
+        contactUrl="http://www.example.com/sample_app/support"
+        contactEmail="sample_app_support@example.com"
+        licenseName="License 2.0"
+        licenseUrl="https://www.example.org/licenses/LICENSE-2.0.html"
+        />
+</mpOpenAPI>
 ----
 
+In MicroProfile MicroProfile OpenAPI 2.0 - feature:mpOpenAPI-3.1[display=3.1], only the first web module of the first deployed application is included in the structured documentation. To include or exclude applications, specify the corresponding elements within the `mpOpenAPI` element.
 
-The following table lists xref:external-configuration.adoc[MicroProfile Config] properties that can be specified to configure which modules or applications are included in the generated OpenAPI documentation. These properties are available when you enable the MicroProfile OpenAPI feature, version 2.0 and later. Alternatively, you can specify the feature:microProfile[display=MicroProfile] convenience feature, version 4.0 or later, which automatically enables the full set of MicroProfile features. For configuration examples, see the feature:mpOpenAPI[display=MicroProfile OpenAPI] feature.
+In the following example, the `sample_app` application consists of an EAR file containing five web modules. By default, only `module-1` is included in the documentation. This configuration includes all modules, then selectively excludes modules 3 and 5. It also provides a custom `info` section for the merged API documentation for modules 1, 2, and 4:
+
+[source,xml]
+----
+<mpOpenAPI>
+  <includeApplication>all</includeApplication>
+  <excludeModule>sample_app/module-3</excludeModule>
+  <excludeModule>sample_app/module-5</excludeModule>
+  <info title="A multi-module sample application"
+        description="This is a sample application."
+        version="2.0.1"
+        termsOfService="http://example.com/sample_app/terms"
+        contactName="API Support"
+        contactUrl="http://www.example.com/sample_app/support"
+        contactEmail="sample_app_support@example.com"
+        licenseName="License 2.0"
+        licenseUrl="https://www.example.org/licenses/LICENSE-2.0.html"
+        />
+</mpOpenAPI>
+----
+
+When you configure OpenAPI documentation in the `server.xml` file, the application name is determined by the value of the `name` attribute when the application is deployed in `server.xml` using `application`, `webApplication`, or `enterpriseApplication`. For example:
+
+[source,xml]
+----
+<webApplication name="application1" location="application1-v1.war" />
+----
+
+If the application is deployed in the `dropins` directory or if the `name` attribute is not specified, the name defaults to the archive filename without the file extension.
+
+For module names, the module name is specified in the web module's `web.xml` file. If no `web.xml` file exists or if it does not specify a name, the module name defaults to the file name without the file extension.
+
+[#mp-config]
+==== Configure application or module documentation by using MicroProfile Config properties
+
+MicroProfile Config provides properties to manage which applications and modules are included in the generated OpenAPI documentation. This option is recommended only for compatibility with applications that already use MicroProfile Config to include or exclude modules or applications fro the API documentation. Newer configurations can instead use the `server.xml` file, as previously described.
+
+When you configure the inclusion or exclusion of modules or applications with MicroProfile Config, the following limitations apply:
+
+- You must configure properties in a source that applies to the entire runtime, such as the `bootstrap.properties`, `jvm.properties`, or `server.env` files, or the `variable` element in the `server.xml` file.
+- Any configuration that is defined in the `server.xml` file to include or exclude modules and applications takes precedence over configuration that is set through MicroProfile Config.
+
+
+The following table lists xref:external-configuration.adoc[MicroProfile Config] properties that can be specified to configure which modules or applications are included in the generated OpenAPI documentation.
 
 .Configuration properties for multiple application and multi-module application support
-[%header,cols="3,6,2,6a"]
+[%header,cols="3,6,6a"]
 |===
 
 |Property name
 |Description
-|Default value
 |Valid values
 
 |`mp.openapi.extensions.liberty.merged.include`
 |This property specifies which modules or applications are included in the generated OpenAPI documentation.
-|`first`
 |
 * `all` +
 This value includes all modules and applications in a deployment.
@@ -163,7 +280,6 @@ This value includes only the first web module of the first application deployed.
 
 |`mp.openapi.extensions.liberty.merged.exclude`
 |This property overrides the `mp.openapi.extensions.liberty.merged.include` property to specify which applications or web modules are excluded from the generated OpenAPI documentation.
-|`none`
 |
 * `none` +
 This value excludes no applications or web modules.
@@ -171,33 +287,44 @@ This value excludes no applications or web modules.
 
 |`mp.openapi.extensions.liberty.merged.info`
 |This property sets the `info` section of the final Open API document. If it is set, the `info` section in the final OpenAPI document is replaced with the value of the property. This replacement is made after any merging is completed.
-|N/A
 |The value must be https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md#infoObject[a valid OpenAPI info section] in JSON format.
 
 |===
 
-=== Resolution of OpenAPI document merging conflicts
-
-When OpenAPI documentation from multiple modules is merged into a single document, Open Liberty applies the following rules to resolve potential conflicts between the OpenAPI documents that are being merged.
 
-- If all server URLs end with the context root, the context root is removed from each server URL and added as a prefix to each path. If no servers exist in a document, the context root is added as a prefix to each path. If the same path is then declared in more than one document, a warning is logged and all but one of the clashing documents is excluded from the merged documentation.
+In the following `jvm.properties` file example, an OpenAPI document is configured for the `sample_app` application, which consists of an EAR file with five web modules.
 
-- If the same extension name is declared with different values at the top level of more than one document, a warning is logged. All but one of the clashing documents are excluded from the merged documentation.
-
-- If the top-level `servers` section is not identical across all documents, each server is removed from the top level and copied under the paths that it applies to.
-
-- Component names are made unique by adding a number to the end of them where necessary. References to the component name are updated.
-
-- Operation IDs are made unique by adding a number to the end of them where necessary. References to the operation ID are updated.
+[source,properties]
+----
+mp.openapi.extensions.liberty.merged.include=all
+mp.openapi.extensions.liberty.merged.exclude=sample_app/module-3,sample_app/module-5
+mp.openapi.extensions.liberty.merged.info=
+{
+  "title": "A multi-module sample application",
+  "description": "This is a sample application.",
+  "termsOfService": "http://example.com/sample_app/terms",
+  "contact": {
+    "name": "API Support",
+    "url": "http://www.example.com/sample_app/support",
+    "email": "sample_app_support@example.com"
+  },
+  "license": {
+    "name": "License 2.0",
+    "url": "https://www.example.org/licenses/LICENSE-2.0.html"
+  },
+  "version": "2.0.1"
+}
+----
 
-- If the `info` section is not identical across all documents, it is replaced by a standard info section that says that the documentation from several modules was merged.
+* The `mp.openapi.extensions.liberty.merged.include` property specifies that all five modules are included in the final OpenAPI document.
+* The `mp.openapi.extensions.liberty.merged.exclude` overrides the `mp.openapi.extensions.liberty.merged.include` property to exclude the `module-3` and `module-5` web modules.
+* The `mp.openapi.extensions.liberty.merged.info` property sets the `info` section for the final OpenAPI document, which documents web modules 1, 2, and 4.
 
-- If the top-level `security` section is not the same across all documents, the security requirements are copied under each operation that they apply to.
+When you configure support for multiple applications and multi-module environments by using MicroProfile Config, the application name is determined from the application's deployment descriptor (`application.xml` or `web.xml`). If the deployment descriptor is missing or does not specify a name, the application name defaults to the application archive file name without the file extension. Similarly, the module name is specified in the web module `web.xml` file. If the `web.xml` file does not exist or does not specify a name, the module name defaults to the file name without the file extension.
 
-- If the `externalDocs` section is not the same across all documents, it is removed from the final document.
+For more information, see the link:/docs/latest/reference/microprofile-config-properties.html#openapi[MicroProfile Config properties for MicroProfile OpenAPI].
 
 
 == See also
 
--
-- Guide: link:/guides/microprofile-config-intro.html[Separating configuration from code in microservices]
+- Guide: link:/guides/microprofile-openapi.html[Documenting RESTful APIs]
diff --git a/modules/ROOT/pages/fault-tolerance.adoc b/modules/ROOT/pages/fault-tolerance.adoc
index d6a5fd8fdb..b000f28751 100644
--- a/modules/ROOT/pages/fault-tolerance.adoc
+++ b/modules/ROOT/pages/fault-tolerance.adoc
@@ -17,10 +17,13 @@ You can build resilient microservices by including fault tolerance policies in y
 
 Microservice-based applications are resilient when they can continue operating if there is a failure or error in some part of the system. Fault tolerance helps applications fail fast and recover smoothly by guiding how and when certain requests occur and by providing fallback strategies to handle common errors. For example, in an airline ticket application, different microservices might support scheduling, purchasing, and customer preferences. If one service fails, fault tolerance policies help contain the error and keep it from taking down the whole application.
 
+
 == MicroProfile Fault Tolerance
 
 The feature:mpFaultTolerance[display=MicroProfile Fault Tolerance] feature defines a standard API to implement a set of fault tolerance policies. The policies that you implement in your code guide how long requests run, when they retry after an error, and what they do to recover when certain requests fail. MicroProfile Fault Tolerance makes it easy to build resilient microservices that provide reliable function, even when errors occur.
 
+When you enable both feature:mpFaultTolerance-4.1[display=MicroProfile Fault Tolerance 4.1] and feature:mpTelemetry-2.0[display=MicroProfile Telemetry 2.0], fault tolerance metrics are automatically collected and exported to the configured OpenTelemetry metrics exporter. For more information, see xref:microprofile-telemetry.adoc[Collect logs, metrics, and traces with OpenTelemetry] and xref:mptelemetry-metrics-list.adoc[MicroProfile Telemetry metrics reference list].
+
 MicroProfile Fault Tolerance supports the following policies:
 
 - <<#timeout,Timeouts>>
@@ -210,5 +213,7 @@ Ready to start building more resilient microservices with MicroProfile Fault Tol
 * To learn how to use the Circuit Breaker and Fallback policies to prevent repeated failed calls to a service, see link:/guides/circuit-breaker.html[Preventing repeated failed calls to microservices].
 
 == See also
+
+- xref:reference:diff/mp-61-70-diff.adoc#ft[Differences between MicroProfile Fault Tolerance 4.1 and 4.0]
+- - xref:reference:diff/mp-33-40-diff.adoc#ft[Differences between MicroProfile Fault Tolerance 3.0 and 2.1]
 - xref:reference:diff/mp-22-30-diff.adoc#ft[Differences between MicroProfile Fault Tolerance 2.0 and 1.1]
-- xref:reference:diff/mp-33-40-diff.adoc#ft[Differences between MicroProfile Fault Tolerance 3.0 and 2.1]
diff --git a/modules/ROOT/pages/introduction-monitoring-metrics.adoc b/modules/ROOT/pages/introduction-monitoring-metrics.adoc
index eabc136145..e448810de8 100644
--- a/modules/ROOT/pages/introduction-monitoring-metrics.adoc
+++ b/modules/ROOT/pages/introduction-monitoring-metrics.adoc
@@ -10,20 +10,18 @@
 :page-type: general
 :page-description: With Open Liberty, three types of metrics are available to monitor your applications: OpenTelemetry metrics provided by MicroProfile Telemetry, REST endpoint-style metrics that are provided by MicroProfile Metrics, and Java Management Extensions (JMX) metrics.
 :seo-title: Monitoring with metrics - OpenLiberty.io
-:seo-description: With Open Liberty, three types of metrics are available to monitor your applications: OpenTelemetry metrics provided by MicroProfile Telemetry, REST endpoint-style metrics that are provided by MicroProfile Metrics, and Java Management Extensions (JMX) metrics..
+:seo-description: With Open Liberty, three types of metrics are available to monitor your applications: OpenTelemetry metrics provided by MicroProfile Telemetry, REST endpoint-style metrics that are provided by MicroProfile Metrics, and Java Management Extensions (JMX) metrics
 = Monitoring with metrics
 
-Three kinds of metrics are available to monitor your Open Liberty applications: OpenTelemetry metrics from MicroProfile Telemetry, REST endpoint-style metrics from MicroProfile Metrics, and Java Management Extensions (JMX) metrics. MicroProfile Metrics and JMX metrics can be used separately or in conjunction to improve the observability of your application systems.
+Three kinds of metrics are available to monitor your Open Liberty applications: OpenTelemetry metrics from MicroProfile Telemetry, REST endpoint-style metrics from MicroProfile Metrics, and Java Management Extensions (JMX) metrics. OpenTelemetry provides a standardized solution to manage metrics, logs, and traces. MicroProfile Metrics and JMX metrics can be used separately or in conjunction to improve the observability of your application systems.
 
 
-MicroProfile Telemetry 2.0 and later exports metrics to OTLP or another configured OpenTelemetry metrics exporter. You might prefer this option if you also use MicroProfile Telemetry to manage your logs and traces.
+MicroProfile Telemetry 2.0 and later exports metrics to the configured OpenTelemetry metrics exporter, which can send metrics to the backend service of your choice. You might prefer this option if you also use MicroProfile Telemetry to manage your logs and traces. The following information pertains to MicroProfile Metrics and JMX Metrics. For information about using OpenTelemetry and MicroProfile Telemetry to collect and export metrics, see xref:microprofile-telemetry.adoc[Collect logs, metrics, and traces with OpenTelemetry].
+
 MicroProfile Metrics can be accessed by monitoring tools, such as Prometheus, or by any client that can make REST requests.
 <<#jmx,JMX metrics>> are suitable for use by Java-based monitoring tools that can communicate with JMX servers, or by custom JMX clients.
 
-[#mptelem]
-== Collect and export metrics with MicroProfile Telemetry
-When you enable the MicroProfile Telemetry feature version 2.0 and later, you can manage your logs, metrics, and traces in a standardized way with the OpenTelemetry protocol. For more information, see xref:microprofile-telemetry.adoc[Enable observability with MicroProfile Telemetry].
-
+  the
 [#endpoint]
 == MicroProfile Metrics and the metrics endpoint
 Open Liberty uses MicroProfile Metrics to expose metrics that describe the internal state of many Open Liberty components. Developers can also use the MicroProfile Metrics API to expose metrics from their applications.
diff --git a/modules/ROOT/pages/microprofile-telemetry.adoc b/modules/ROOT/pages/microprofile-telemetry.adoc
index 063010e302..a39e4a2372 100644
--- a/modules/ROOT/pages/microprofile-telemetry.adoc
+++ b/modules/ROOT/pages/microprofile-telemetry.adoc
@@ -1,4 +1,4 @@
-// Copyright (c) 2022 IBM Corporation and others.
+// Copyright (c) 2024 IBM Corporation and others.
 // Licensed under Creative Commons Attribution-NoDerivatives
 // 4.0 International (CC BY-ND 4.0)
 //   https://creativecommons.org/licenses/by-nd/4.0/
@@ -10,57 +10,67 @@
 :seo-description:
 :page-layout: general-reference
 :page-type: general
-= Enable observability with MicroProfile Telemetry
+= Collect logs, metrics, and traces with OpenTelemetry
 
-With MicroProfile Telemetry 2.0 and later, you can manage logs, metrics, and traces in a standardized way by using the OpenTelemetry protocol.
-MicroProfile Telemetry is based on the OpenTelemetry project, a collection of open source vendor-independent tools, APIs, and SDKs for creating and managing logs, metrics, and trace data.
+The OpenTelemetry project is a collection of open source, vendor-independent resources for collecting and managing application telemetry data. With Open Liberty and MicroProfile Telemetry 2.0 and later, you can manage logs, metrics, and traces in a standardized way by using the OpenTelemetry protocol.
 
-The following sections explain how to prepare your Open Liberty runtime and application code to use MicroProfile Telemetry.
+OpenTelemetry provides a link:https://opentelemetry.io/docs/collector/[collector] component that can receive telemetry data from your runtime and applications and export it to backend services of your choice for monitoring and analysis. By default, all OpenTelemetry data is exported by using the OpenTelemetry Protocol (OTLP). OTLP defines the encoding of telemetry data and the protocol that is used to exchange data between a client and server. Many backend services accept OTLP data without requiring conversion, but OpenTelemetry also provides a collection of service-specific exporters for popular open source and commercial services, such as link:https://grafana.com/blog/2024/03/13/an-opentelemetry-backend-in-a-docker-image-introducing-grafana/otel-lgtm/[Grafana] and link:https://prometheus.io/[Prometheus]. You can configure exporter settings by specifying system properties or environment variables.
+
+OpenTelemetry is implemented in Open Liberty through the feature:mpTelemetry[display=MicroProfile Telemetry] feature. When you enable the MicroProfile Telemetry feature 2.0 or later and specify the required configuration property, Open Liberty automatically collects and exports logs, traces, and metrics at the application or runtime level. For many common application scenarios, no changes are needed in your application code to collect this data. MicroProfile Telemetry 1.1 and earlier enables only the collection of traces and only at the application level.
 
 
-- <<#global, Enabling MicroProfile Telemetry for Open Liberty>>
-- <<#traces, Collecting traces>>
-- <<#logs, Collecting logs>>
-- <<#metrics, Collecting metrics>>
-- <<#trouble, Troubleshooting>>
 
 [#global]
-== Enabling MicroProfile Telemetry for Open Liberty
+== Collecting and exporting logs, metrics, and traces with OpenTelemetry
 
-To enable MicroProfile Telemetry in your Open Liberty runtime, you must add the MicroProfile Telemetry feature to your `server.xml` file and enable the OpenTelemetry SDK. OpenTelemetry is disabled by default. Depending on your needs, you can configure OpenTelemetry SDK instances at the runtime level or the application level. In most cases, runtime-level configuration is preferred as it includes both runtime-level telemetry and application-specific telemetry.
+To collect and export logs, metrics, and traces with OpenTelemetry in your Open Liberty runtime, you must add the MicroProfile Telemetry feature to your `server.xml` file and specify the `otel.sdk.disabled=false` system property in one of the valid configuration sources. Depending on whether your runtime hosts a single application or multiple applications, you can specify this property at the runtime level or the application level. In most cases, runtime-level configuration is preferred because it includes both runtime-level telemetry and application-specific telemetry. The following table summarizes the benefits and use cases for each option.
 
-Runtime-level configuration::
-Runtime-level configuration collects and emits telemetry from the runtime and all applications. As all telemetry from the runtime and applications is labeled as coming from the same service, this configuration works best when you are running a single application per Liberty runtime.
-+
-You can configure your runtime instance in a few different sources, including your `jvm.options`, `bootstrap.properties`, or `server.env` files. You do not need to modify your application configuration to configure your runtime instance.
+.OpenTelemetry configuration options
+[options="header"cols="2,2,6a,6a"]
+|===
+|Configuration level | Use case | Description | Configuration sources
 
-Application-level configuration::
-Configuring application-level OpenTelemetry instances gives you more fine-grained control over the data you collect for each application. This option also supports configuration compatibility with feature:mpTelemetry-1.1[display=MicroProfile Telemetry 1.1] and earlier, which created only application-level SDK instances. Runtime-level data is not collected or emitted by application-level instances.
+| <<#runtime, Runtime level>>
+| One application per Liberty runtime
+| Collects and emits telemetry from both the runtime and the application.
+| * `bootstrap.properties` file
+* `jvm.options` file
+* `server.env` file
 +
-You can configure your application-level OpenTelemetry instances in the `microprofile-config.properties` file or the `appProperties` attribute for the config:application[] element in the `server.xml` file. When you create application-level instances, any system and server environment properties overwrite your application-level configuration.
+If you choose to use the `server.env` file, specify the `OTEL_SDK_DISABLED=false` environment variable instead of the configuration property.
 
-For more information about configuration sources and their ordinal values, see xref:external-configuration.adoc#default[Default configuration sources].
+| <<#app, Application level>>
+| Multiple applications in the same Liberty runtime
+| Collects and emits telemetry for a single application and does not include runtime-level data. Provides fine-grained control over data collection for each application.
+| * `microprofile-config.properties` file
+* `appProperties` attribute for the config:application[] element in the `server.xml` file.
+|===
 
-To enable MicroProfile Telemetry to collect and emit logs, metrics, and traces, complete the following steps.
+[#runtime]
+=== Enabling OpenTelemetry for an Open Liberty runtime with a single application
 
-. Enable the feature:mpTelemetry[display=MicroProfile Telemetry] feature in your `server.xml` file. To export metrics or logs, you must enable `mpTelemetry-2.0` or later.
+When your Open Liberty runtime hosts only one application, you can enable OpenTelemetry at the runtime level to collect and export logs, metrics, and traces for both the runtime and the application.
 
-. Set the `otel.sdk.disabled=false` property at the runtime level or the application level.
-+
-At runtime initialization, if the `otel.sdk.disabled` property is set to `false`, the runtime-level OpenTelemetry SDK instance is created. If the runtime instance is not enabled and `otel.sdk.disabled=false` is specified at the application level, an application-level instance is created during application initialization.
+. Enable the feature:mpTelemetry[display=MicroProfile Telemetry] feature version 2.0 or later in the `featureManager` element of your `server.xml` file.
 
-.. To enable the OpenTelemetry SDK at the runtime level, set the `otel.sdk.disabled=false` property as a system property, for example, in the `bootstrap.properties` file:
+. Set `otel.sdk.disabled=false` as a runtime-level property, for example, in the xref:reference:config/server-configuration-overview.adoc#bootstrap-properties[bootstrap.properties] file:
 +
 ----
 otel.sdk.disabled=false
-otel.service.name=RT1
 ----
-+
-The `otel.service.name` property creates a name for any telemetry that this OpenTelemetry SDK instance collects and emits.
-+
-Alternatively, you can set runtime-level configuration properties by using environment variables in your `server.env` file. For any property definition, make the key name uppercase and convert any punctuation to underscores. For example, the `otel.sdk.disabled=false` property is equivalent to the `OTEL_SDK_DISABLED=false` environment variable.
 
-.. To enable the OpenTelemetry SDK at the application level, set the `otel.sdk.disabled=false` property in the `microprofile-config.properties` file of each application.
+After you enable the MicroProfile Telemetry feature and set this system property, your runtime is ready to start collecting and exporting logs, metrics, and traces from the application and the runtime. For more information, see <<config,OpenTelemetry settings and configuration>>.
+
+[#app]
+=== Enabling OpenTelemetry for multiple applications in the same Open Liberty runtime
+
+When your Liberty runtime hosts multiple applications, you might choose to enable OpenTelemetry to collect logs, metrics, and traces at the application level for each application. Although this option does not collect runtime-level telemetry, it gives you fine-grained control of the data you collect for each application.
+
+. Enable the feature:mpTelemetry[display=MicroProfile Telemetry] feature version 2.0 or later in the `featureManager` element of the `server.xml` file of each application that you want to collect telemetry for.
+
+. Set `otel.sdk.disabled=false` as an application-level property in the `microprofile-config.properties` file of each application.
++
+The following examples show an application scenario where two applications on the same Open Liberty runtime are configured to collect and export telemetry data at the application level. These examples also set the `otel.service.name` property in each application to assign a service name to the telemetry data that is collected. This service name helps you identify the source of the data from each application when you send your data to monitoring and analytics tools.
 +
 Application 1 `microprofile-config.properties` file:
 +
@@ -76,195 +86,80 @@ otel.sdk.disabled=false
 otel.service.name=A2
 ----
 +
-This configuration creates all telemetry from Application 1 with the service name `A1`, and from Application 2 with the service name `A2`. It omits all runtime-level telemetry.
+This configuration creates all telemetry from Application 1 with the service name `A1`, and from Application 2 with the service name `A2`.
 
-.. Optionally, use a combination of application-level and runtime-level configuration.
-+
-Regardless of whether a runtime instance is created, any configuration in the system properties and server environment variables takes precedence over application-level configuration. Therefore, you can configure shared application configuration at the runtime level and make application-specific changes in your application configuration.
-+
-For example, you can set the OpenTelemetry exporter at the runtime-level in the `bootstrap.properties` file:
-+
-----
-otel.logs.exporter=myExporter
-----
-+
-Then, enable an application-level OpenTelemetry SDK instance in the `microprofile-config.properties` file for each application in the runtime:
-+
-----
-otel.sdk.disabled=false
-otel.service.name=<serviceName>
-----
-+
-This configuration enables an application-level SDK instance and custom service name for each configured application, while all applications in the runtime use the `myExporter` OpenTelemetry exporter.
-
-
-[#traces]
-== Configuring Open Liberty to use MicroProfile Telemetry to collect traces
 
-One way to increase observability of an application is by emitting traces. Traces represent requests and consist of multiple spans. A span represents a single operation in a request. It includes a name, time-related data, log messages, and metadata about what happens during a transaction.
+You can also use a combination of runtime-level and application-level configuration, so that some settings apply to all applications on the runtime, while others are specific to each application. This strategy can save you from having to duplicate general configuration settings in multiple applications on the same runtime.
 
-MicroProfile Telemetry replaces MicroProfile OpenTracing. For more information about migrating your applications from MicroProfile OpenTracing to MicroProfile Telemetry, see xref:reference:diff/mp-50-60-diff.adoc#telemetry[Differences between MicroProfile Telemetry 1.0 and MicroProfile OpenTracing 3.0].
+Any runtime-level configuration takes precedence over application-level configuration. Therefore, you can enable OpenTelemetry and assign a service name individually for each application, but specify other settings at the runtime level to apply globally to all applications on the runtime. To combine runtime and application-level configuration, you must set the `otel.sdk.disabled=false` property at the application level and not in a runtime-level configuration source.
 
-. Enable the MicroProfile Telemetry feature and specify a MicroProfile Config property or environment variable to enable the OpenTelemetry SDK.
-+
-For more information, see <<#global,Enabling MicroProfile Telemetry for Open Liberty>>
+For example, you might want to collect a unique set of telemetry data for each application in the runtime, but have all applications use the same OpenTelemetry logs exporter. You can set the OpenTelemetry logs exporter at the runtime-level by adding the following property in the `bootstrap.properties` file:
 
-. Configure a trace storage system by specifying an exporter definition that includes the exporter type and endpoint.
-+
-For example, to use a Jaeger server or to forward data to an OpenTelemetry collector, you might add configuration similar to the following example to your `bootstrap.properties` file:
-+
-[source,properties]
 ----
-otel.sdk.disabled=false
-otel.traces.exporter=otlp
-otel.exporter.otlp.endpoint=http://localhost:4317/
-----
-+
-Alternatively, to use a Zipkin server, you might add configuration similar to the following example to your `bootstrap.properties` file:
-+
-[source,properties]
-----
-otel.sdk.disabled=false
-otel.traces.exporter=zipkin
-otel.exporter.zipkin.endpoint=http://localhost:9411/api/v2/spans
+otel.logs.exporter=myExporter
 ----
 
-. Optionally, set other MicroProfile Config properties to configure trace details.
-+
-For example, if you want to export traces to Open Liberty log files, set the following property:
-+
-[source,properties]
+Then, enable application-level telemetry and specify a service name in the `microprofile-config.properties` file for each application in the runtime:
+
 ----
-otel.traces.exporter=console
+otel.sdk.disabled=false
+otel.service.name=<serviceName>
 ----
-+
-For more information about the available properties, see xref:reference:microprofile-config-properties.adoc#telemetry[MicroProfile Config properties: MicroProfile Telemetry].
 
-. Depending on how you choose to instrument your application code for tracing, further configuration might be required.
-+
-For more information, see xref:telemetry-trace.adoc#t[Code instrumentation for MicroProfile Telemetry tracing].
+This configuration enables an application-level telemetry with a unique service name for each application, while all applications in the runtime use the `myExporter` logs exporter.
 
-[#logs]
-== Configuring Open Liberty to use MicroProfile Telemetry to collect logs
+After you enable the MicroProfile Telemetry feature and set the system properties for each application on the runtime, your applications are ready to start collecting and exporting logs, metrics, and traces.
 
-To enable MicroProfile Telemetry to collect and export logs in your Open Liberty runtime, add the MicroProfile Telemetry feature 2.0 or later to your `server.xml` file and enable the OpenTelemetry SDK. Optionally, you can specify MicroProfile Config properties to configure how MicroProfile Telemetry collects and exports logs.
+[#config]
+== OpenTelemetry settings and configuration
 
-. Enable the MicroProfile Telemetry feature 2.0 or later and specify a MicroProfile Config property or environment variable to enable the OpenTelemetry SDK.
-+
-For more information, see <<#global,Enabling MicroProfile Telemetry for Open Liberty>>.
+By default, all OpenTelemetry data is exported by using the link:https://github.com/open-telemetry/oteps/blob/main/text/0035-opentelemetry-protocol.md[OpenTelemetry Protocol] (OTLP) at the `\http://localhost:4317` endpoint. You can configure alternative exporter settings by specifying system properties or environment variables. Open Liberty supports all link:https://opentelemetry.io/docs/languages/java/configuration/#environment-variables-and-system-properties[OpenTelemetry Java configuration properties].
 
-. Optionally, configure the log sources that MicroProfile Telemetry collects and where the logs are exported.
-+
-You can configure how MicroProfile Telemetry collects and exports logs by specifying configuration properties in any of the xref:external-configuration.adoc#default[config sources that are available to MicroProfile Config], or by specifying environment variables.
-
-.. Enable MicroProfile Telemetry to collect logs from different sources in the Open Liberty runtime environment.
-+
-Configure the `source` attribute for the `mpTelemetry` element with a comma-separated list of log sources:
-+
-[source,xml]
-----
-<mpTelemetry source="message, trace, ffdc"/>
-----
-+
-The `mpTelemetry` configuration element is optional. If you do not specify it, or if you do not include the `source` attribute, the default configuration source is `message`. For more information, see feature:mpTelemetry-2.0[display=Collect logs from a specified source].
+To change the endpoint that the default `otlp` exporter uses, set the `otel.exporter.otlp.endpoint` property. For example, you can set the following property in the `bootstrap.properties` file to change the endpoint for all `otlp` logs, metrics, and traces from the `\http://localhost:4317` default to `\http://localhost:9080`:
 
-.. Change the log exporter that MicroProfile Telemetry uses.
-+
-By default, all OpenTelemetry data is exported to link:https://opentelemetry.io/docs/languages/java/exporters/#otlp[OTLP]. You can change this setting by specifying the `otel.logs.exporter` property.
-+
-For example, to send logs to the `console.log` file for debugging purposes, you might add configuration similar to the following example to your `bootstrap.properties` file:
-+
 [source,properties]
 ----
-otel.sdk.disabled=false
-otel.logs.exporter=console
+otel.exporter.otlp.endpoint=http://localhost:9080
 ----
-+
-If you set this property to `console`, all the logs are exported to standard out (`stdout`) or the `console.log` file. The `console.log` file contains the usual logs, along with duplicate OpenTelemetry-mapped logs. This setting is only for debugging purposes because the `console.log` file does not roll over and might affect performance if it gets too large. If you set this property to `none`, no logs are exported.
-+
-.. Configure MicroProfile Telemetry to use the OpenTelemetry Batch LogRecord Processor.
-+
-By default, the `SimpleLogRecordProcessor` is enabled, so the records are sent immediately. However, if you want to send the records in batches, you can also configure the following logging-specific Batch LogRecord Processor properties or environment variables:
-+
-* `otel.blrp.schedule.delay` or `OTEL_BLRP_SCHEDULE_DELAY`
-* `otel.blrp.max.queue.size` or `OTEL_BLRP_MAX_QUEUE_SIZE`
-* `otel.blrp.max.export.batch.size` or `OTEL_BLRP_MAX_EXPORT_BATCH_SIZE`
-* `otel.blrp.export.timeout` or `OTEL_BLRP_EXPORT_TIMEOUT`
-+
-For more information, see the OpenTelemetry link:https://opentelemetry.io/docs/specs/otel/configuration/sdk-environment-variables/#batch-logrecord-processor[Batch LogRecord Processor] documentation.
 
-For more information about the available properties, see xref:reference:microprofile-config-properties.adoc#telemetry[MicroProfile Config properties: MicroProfile Telemetry].
+If you want to change the exporter that OpenTelemetry uses for logs, metrics, or traces, set the `otel.< _signal_ >.exporter` property, where `_signal_` is the type of data that you want to change the exporter for: logs, metrics, or traces. For example, if you use Zipkin to manage your trace data, you can set the following property in the `bootstrap.properties` file to export your application and runtime traces to a configured Zipkin server:
 
-For information about Liberty message event fields for MicroProfile Telemetry, see xref:mptel-log-events-list.adoc[MicroProfile Telemetry log events reference list].
-
-[#metrics]
-== Configuring Open Liberty to use MicroProfile Telemetry to collect metrics
-
-To enable MicroProfile Telemetry to collect and export metrics in your Open Liberty runtime, add the MicroProfile Telemetry 2.0 feature to your `server.xml` file and enable the OpenTelemetry SDK. Optionally, you can specify MicroProfile Config properties to configure how MicroProfile Telemetry collects and exports metrics.
-
-. Enable the MicroProfile Telemetry feature 2.0 or later and specify a MicroProfile Config property or environment variable to enable the OpenTelemetry SDK.
-+
-For more information, see <<#global,Enabling MicroProfile Telemetry for Open Liberty>>
-
-. Optionally, change the log exporter that MicroProfile Telemetry uses.
-+
-By default, all OpenTelemetry data is exported to link:https://opentelemetry.io/docs/languages/java/exporters/#otlp[OTLP]. You can change this setting by specifying the `otel.metrics.exporter` property or the `OTEL_METRICS_EXPORTER` environment variable.
-+
-For example, to export metrics to Open Liberty log files, specify the following property:
-+
+[source, properties]
 ----
-otel.metrics.exporter=console
+otel.traces.exporter=zipkin
 ----
 
-. Optionally, change the metric export interval.
-+
-By default, metric data is exported at an interval of 60 seconds. To modify the export interval, specify the `otel.metric.export.interval` property or the `OTEL_METRIC_EXPORT_INTERVAL` environment variable. Specify the value in milliseconds. For more information, see link:https://opentelemetry.io/docs/specs/otel/configuration/sdk-environment-variables/#periodic-exporting-metricreader[Periodic exporter MetricReader] in the OpenTelemetry documentation.
+When you change the exporter value to `zipkin`, OpenTelemetry exports traces to the `\http://localhost:9411/api/v2/spans` endpoint instead of the OTLP default endpoint. You can configure a different endpoint by setting the `otel.exporter.zipkin.endpoint` property value to your chosen endpoint.
 
-Depending on how you choose to instrument your application code for metrics, further configuration might be required. For information about defining your own metrics, see xref:custom-mptelemetry-metrics.adoc[Define custom MicroProfile Telemetry metrics].
+For debugging purposes, you can also temporarily configure your logs, metrics, or traces to be exported to the `console.log` file. For more information, see xref:telemetry-troubleshooting.adoc#console[Exporting logs, metrics, or traces to the console for debugging purposes].
 
-For a list of metrics that are available for Open Liberty when you enable the MicroProfile Telemetry feature 2.0 or later, see xref:mptelemetry-metrics-list.adoc[MicroProfile Telemetry metrics reference list].
+For information about commonly-used configuration properties for logs, metrics, and trace settings, see xref:reference:microprofile-config-properties.adoc#telemetry[MicroProfile Telemetry: OpenTelemetry properties].
 
-[#trouble]
-== Troubleshooting MicroProfile Telemetry
-The following information can help you determine the cause of common problems and error messages.
+[#traces]
+=== Trace defaults
 
-Previous spans are incorrectly shown as current or parent spans::
+When you enable OpenTelemetry for Open Liberty, Jakarta RESTful Web Services and JAX-RS applications are instrumented for trace by default. Spans are automatically generated for incoming HTTP requests, including static files, servlets, and JSPs. These spans are automatically exported according to the configured OpenTelemetry exporter settings.
 
-If the `Scope` instance is not closed correctly, the context and baggage values of previous spans might remain when the next operation executes. Alternatively, the current span might remain and be picked up as the parent of the next operation that executes.
-+
-Always close the `Scope` instance when you exit an operation. This configuration stops the span from being current and makes the previous span current again. Use a `try-with-resources` block, which automatically closes the `Scope` instance at the end of the block, as shown in the following example:
-+
-[source, java]
-----
-Span span = tracer.spanBuilder("PerformingOperation").startSpan();
-try (Scope scope = span.makeCurrent()) {
-    ...
-} finally {
-    span.end();
-}
-----
+Automatic instrumentation is available only for JAX-RS and Jakarta RESTful web service applications. To create spans for other operations, such as database calls, you can add manual instrumentation to the source code for those operations by using the OpenTelemetry API. Alternatively, you can attach the OpenTelemetry Java agent to any Java 8+ application. For more information about these options, see xref:telemetry-trace.adoc[Code instrumentation for MicroProfile Telemetry tracing].
 
-You receive the `CWMOT5100I` message that tracing is disabled::
+[#logs]
+=== Logs defaults
+OpenTelemetry automatically collects runtime and application logs that are sent to the `java.util.logging` API. Any events that are logged at a `java.util.logging.Level` log level of `INFO` and above are considered messages. Levels below `INFO` are considered trace. By default, OpenTelemetry logging automatically collects messages, but you can configure it to collect from other sources in your `server.xml` file. For more information, see link:/docs/latest/reference/feature/mpTelemetry-2.0.html#_collect_logs_from_a_specified_source[Collect logs from a specified source].
 
-If you enable the `mpTelemetry-1.1` or `mpTelemetry-1.0` feature, you must also set the `otel.sdk.disabled=false` property in any of the configuration sources that are accessible through MicroProfile Config to enable tracing.
+For information about Liberty log event fields for OpenTelemetry, see xref:mptel-log-events-list.adoc[MicroProfile Telemetry log events reference list].
 
-You receive the CWMOT5003W message that the application attempted to acquire MicroProfile Telemetry after shut down::
 
-Review the application to see why it attempted to use MicroProfile Telemetry after it shut down. Actions that might trigger MicroProfile Telemetry include calling a method that is annotated with `@WithSpan` or making a request with a JAX-RS Client or MP Rest Client.
+When you use the `otlp` default log exporter, the OpenTelemetry Batch LogRecord Processor (BLRP) is enabled and log records are exported in batches according to BLRP default settings. You can adjust these settings with `otel.blrp.*` properties. For more information about the available properties and their default settings, see xref:reference:microprofile-config-properties.adoc#telemetry[MicroProfile Telemetry: OpenTelemetry properties].
 
-You receive either of the CWMOT5006W or CWMOT5007 warning message that conflicting configuration is specified for otel.sdk.disabled::
+[#metrics]
+=== Metrics defaults
 
-Specify the settings to enable or disable OpenTelemetry instances by using either environment variables or MicroProfile Config sources, but not both. If you see these warnings, the other MicroProfile Config source to look at is your `server.xml` file.
+When you enable OpenTelemetry for Open Liberty, a default set of metrics is automatically collected and exported according to the configured OpenTelemetry exporter settings. For more information about these metrics, see the xref:mptelemetry-metrics-list.adoc[MicroProfile Telemetry metrics reference list]. You can also use the OpenTelemetry API to xref:custom-mptelemetry-metrics.adoc[define custom metrics] in your application code for OpenTelemetry to collect and export.
+
+You can configure the metrics exporter settings, including the export interval and timeout values, by setting system properties. For more information, see xref:reference:microprofile-config-properties.adoc#telemetry[MicroProfile Telemetry: OpenTelemetry properties].
 
-////
-+
-Different versions of the MicroProfile Telemetry feature are compatible with different MicroProfile versions, Jakarta and Java Enterprise Editions, and the Open Liberty umbrella features that support them. Both feature:mpTelemetry-1.0[] and feature:mpTelemetry-1.1[] are compatible with feature:jakartaee-10.0[] and feature:microProfile-6.0[]. However, `mpTelemetry-1.1` is also compatible with the following earlier umbrella features:
-+
-*  feature:javaee-7.0[] and feature:microProfile-1.4[]
-*  feature:jakartaee-8.0[] and feature:microProfile-4.1[]
-*  feature:jakartaee-9.1[] and feature:microProfile-5.0[]
-////
 
 == See also
 
-https://opentelemetry.io/[OpenTelemetry project]
+* xref:telemetry-troubleshooting.adoc[Troubleshooting OpenTelemetry]
+* https://opentelemetry.io/[OpenTelemetry project]
diff --git a/modules/ROOT/pages/microprofile.adoc b/modules/ROOT/pages/microprofile.adoc
index d9ebe32816..78b8e0b195 100644
--- a/modules/ROOT/pages/microprofile.adoc
+++ b/modules/ROOT/pages/microprofile.adoc
@@ -122,7 +122,7 @@ For more information, see xref:microservice-observability-metrics.adoc[Microserv
 === Enable distributed tracing of your microservices
 link:https://projects.eclipse.org/projects/technology.microprofile/releases/microprofile-telemetry-1.0/plan%E2%80%A8%E2%80%A822.0.0.10-bet[MicroProfile Telemetry] is based on the https://opentelemetry.io/[OpenTelemetry project], which is a collection of open source vendor-agnostic tools, APIs, and SDKs for creating and managing trace data.
 
-In Open Liberty, MicroProfile Telemetry is supported by the feature:mpTelemetry[display=MicroProfile Telemetry] feature. You can export the data that this feature collects to tracing systems such as Jaeger or Zipkin. For more information, see xref:microprofile-telemetry.adoc[Enable observability with MicroProfile Telemetry].
+In Open Liberty, MicroProfile Telemetry is supported by the feature:mpTelemetry[display=MicroProfile Telemetry] feature. You can export the data that this feature collects to tracing systems such as Jaeger or Zipkin. For more information, see xref:microprofile-telemetry.adoc[Collect logs, metrics, and traces with OpenTelemetry].
 
 MicroProfile Telemetry replaces MicroProfile OpenTracing. For information about migrating your applications from MicroProfile OpenTracing to MicroProfile Telemetry, see xref:reference:diff/mp-50-60-diff.adoc#telemetry[Differences between MicroProfile Telemetry 1.0 and MicroProfile OpenTracing 3.0].
 
diff --git a/modules/ROOT/pages/mptel-log-events-list.adoc b/modules/ROOT/pages/mptel-log-events-list.adoc
index 6778871dc1..251f35a129 100644
--- a/modules/ROOT/pages/mptel-log-events-list.adoc
+++ b/modules/ROOT/pages/mptel-log-events-list.adoc
@@ -14,16 +14,17 @@
 
 MicroProfile Telemetry can collect logging events from the server runtime and applications. You can use these events to gather and analyze data that can help to better understand the behavior of applications.
 
-For more information, see xref:microprofile-telemetry.adoc[Enable observability with MicroProfile Telemetry].
+For more information, see xref:microprofile-telemetry.adoc[Collect logs, metrics, and traces with OpenTelemetry].
 
 MicroProfile Telemetry can collect the following types of events:
 
-* <<Message events, Message events>>
-* <<Trace events, Trace events>>
-* <<FFDC events, FFDC events>>
+* <<#me, Message events>>
+* <<#te, Trace events>>
+* <<#ffdce, FFDC events>>
 
 For information about trace log detail levels and how Open Liberty settings map to OpenTelemetry severity numbers, see <<sevlev, OpenTelemetry severity number mapping with Liberty log levels>>.
 
+[#me]
 == Message events
 The following table provides the fields for Liberty message events, a description for each field, and the mapping to the OpenTelemetry logs data model and Java agent:
 
@@ -66,6 +67,8 @@ Attributes:
             io.openliberty.ext.app_name="badapp"
 ----
 
+
+[#te]
 == Trace events
 The following table provides the fields for Liberty trace events, a description for each field, and the mapping to the OpenTelemetry logs data model and Java agent:
 
@@ -107,6 +110,7 @@ Attributes:
             io.openliberty.ext.app_name="testapp"
 ----
 
+[#ffdce]
 == FFDC events
 The following table provides the fields for the first failure data capture (FFDC) events, a description for each fiel, and the mapping to the OpenTelemetry logs data model:
 
diff --git a/modules/ROOT/pages/mptelemetry-logging.adoc b/modules/ROOT/pages/mptelemetry-logging.adoc
index fc33ea12c9..f6ff5490fa 100644
--- a/modules/ROOT/pages/mptelemetry-logging.adoc
+++ b/modules/ROOT/pages/mptelemetry-logging.adoc
@@ -16,4 +16,4 @@ You can use MicroProfile Telemetry to mange your logs, along with traces and met
 
 Any messages that are logged at a `java.util.logging.Level` log level of `INFO` and above are considered messages. Levels below `INFO` are considered trace. By default, MicroProfile Telemetry automatically collects messages, but you can configure the sources that it collects from in your `server.xml` file. For more information, see link:/docs/latest/reference/feature/mpTelemetry-2.0.html#_collect_logs_from_a_specified_source[Collect logs from a specified source].
 
-For more information about configuring MicroProfile Telemetry to collect and emit logs, metrics, and trace, see xref:microprofile-telemetry.adoc[Enable observability with MicroProfile Telemetry].
+For more information about configuring MicroProfile Telemetry to collect and emit logs, metrics, and trace, see xref:microprofile-telemetry.adoc[OpenTelemetry].
diff --git a/modules/ROOT/pages/mptelemetry-metrics-list.adoc b/modules/ROOT/pages/mptelemetry-metrics-list.adoc
index 79b23d1044..b9729ea576 100644
--- a/modules/ROOT/pages/mptelemetry-metrics-list.adoc
+++ b/modules/ROOT/pages/mptelemetry-metrics-list.adoc
@@ -19,6 +19,8 @@
 :mp-4-0: feature:mpMetrics-4.0[display=MicroProfile Metrics 4.0]
 :mp-5-0: feature:mpMetrics-5.0[display=MicroProfile Metrics 5.0]
 :mp-ft-3-0: feature:mpFaultTolerance-3.0[display=MicroProfile Fault Tolerance 3.0]
+:mp-tel-2-0: feature:mpTelemetry-2.0[display=MicroProfile Telemetry 2.0]
+:mp-tel-2-0-ft-4-1: feature:mpTelemetry-2.0[display=MicroProfile Telemetry 2.0] and feature:mpFaultTolerance-4.1[display=MicroProfile Fault Tolerance 4.1]
 :connector-metric-features: feature:mpMetrics[display=MicroProfile Metrics] and feature:mpReactiveMessaging[display=MicroProfile Reactive Messaging 3.0]
 :base-metric-features: feature:mpMetrics[display=MicroProfile Metrics]
 :vendor-metric-features: feature:mpMetrics[display=MicroProfile Metrics]
@@ -32,7 +34,7 @@ Use metric data to effectively monitor the status of your microservice systems.
 
 You can obtain metrics from applications, the Open Liberty runtime, and the Java virtual machine (JVM). They can be gathered and stored in database tools, such as link:https://prometheus.io/[Prometheus], and displayed on dashboards, such as link:https://grafana.com/[Grafana].
 
-When you enable the feature:mpTelemetry-2.0[display=MicroProfile Telemetry] feature version 2.0 and later, you can manage your logs, metrics, and traces in a standardized way with the OpenTelemetry protocol. For more information, see xref:microprofile-telemetry[Enable observability with MicroProfile Telemetry].
+When you enable the feature:mpTelemetry-2.0[display=MicroProfile Telemetry] feature version 2.0 and later, you can manage your logs, metrics, and traces in a standardized way with the OpenTelemetry protocol. For more information, see xref:microprofile-telemetry[Collect logs, metrics, and traces with OpenTelemetry].
 
 
 == Filter metrics to gather only the data you need
@@ -62,7 +64,7 @@ To disable all monitoring components, add the following code to your `server.xml
 
 == MicroProfile Telemetry 2.0 and later metrics reference
 
-When the MicroProfile Telemetry feature 2.0 and later is enabled, Open Liberty can send metric data to compatible OpenTelemetry protocol (OTLP) receivers. For more information, see xref:microprofile-telemetry[Enable observability with MicroProfile Telemetry].
+When the MicroProfile Telemetry feature 2.0 and later is enabled, Open Liberty can send metric data to compatible OpenTelemetry protocol (OTLP) receivers.
 
 The table lists the metric types, descriptions and attributes that are available for Open Liberty. Where applicable, the associated monitoring component that you can use to filter the metric is also included.
 The **Features required** column of the table includes the feature or features that must be enabled to obtain that metric data.
@@ -75,6 +77,112 @@ The **Version introduced** column specifies the minimum version of the feature t
 |===
 | MicroProfile Telemetry 2.0 name | Attributes | Type and description | Monitoring component | Features required | Version introduced
 
+| ft.bulkhead.calls.total
+| * `method`: The fully qualified method name
+* `bulkheadResult = [accepted\|rejected]`: Whether the bulkhead allowed the method call to run
+| The number of times the bulkhead logic was run. This value is typically equal to once per method call. However, it might be zero if the circuit breaker prevents execution or more than once per method call if the method is retried. This metric is a `LongCounter`.
+| n/a
+| {mp-tel-2-0-ft-4-1}
+| {mp-tel-2-0}
+
+| ft.bulkhead.executionsRunning
+| `method`: The fully qualified method name
+| Number of currently running executions. This metric is a `LongUpDownCounter`.
+| n/a
+| {mp-tel-2-0-ft-4-1}
+| {mp-tel-2-0}
+
+| ft.bulkhead.executionsWaiting
+| `method`: The fully qualified method name
+| Number of executions that are currently waiting in the queue. This metric is a `LongUpDownCounter`.
+| n/a
+| {mp-tel-2-0-ft-4-1}
+| {mp-tel-2-0}
+
+| ft.bulkhead.runningDuration
+| `method`: The fully qualified method name
+| Histogram of the time that method executions spent running. This metric is a `DoubleHistogram`.
+| n/a
+| {mp-tel-2-0-ft-4-1}
+| {mp-tel-2-0}
+
+| ft.bulkhead.waitingDuration
+| `method`: The fully qualified method name
+| Histogram of the time that method executions spent waiting in the queue. This metric is a `DoubleHistogram`.
+| n/a
+| {mp-tel-2-0-ft-4-1}
+| {mp-tel-2-0}
+
+| ft.circuitbreaker.calls.total
+| * `method`: The fully qualified method name
+    * `circuitBreakerResult = [success\|failure\|circuitBreakerOpen]`: The result of the method call, as considered by the circuit breaker according to the rules in https://download.eclipse.org/microprofile/microprofile-fault-tolerance-4.0.2/microprofile-fault-tolerance-spec-4.0.2.html#circuit-breaker-success-failure[Configuring which exceptions are considered a failure]
+        ** `success`: The method ran and was successful
+        **  `failure`: The method ran and failed
+        ** `circuitBreakerOpen`: The method did not run because the circuit breaker was in open or half-open state
+
+| The number of times the circuit breaker logic was run. This value is typically equal to once per method call, but might be more than once if the method is retried. This metric is a `LongCounter`.
+| n/a
+| {mp-tel-2-0-ft-4-1}
+| {mp-tel-2-0}
+
+| ft.circuitbreaker.opened.total
+| `method`: The fully qualified method name
+| Number of times the circuit breaker moved from closed state to open state. This metric is a `LongCounter`.
+| n/a
+| {mp-tel-2-0-ft-4-1}
+| {mp-tel-2-0}
+
+| ft.circuitbreaker.state.total
+| * `method`: The fully qualified method name
+ * `state = [open\|closed\|halfOpen]`: The circuit breaker state
+| Amount of time the circuit breaker spent in each state. This metric is a `LongCounter`.
+| n/a
+| {mp-tel-2-0-ft-4-1}
+| {mp-tel-2-0}
+
+| ft.invocations.total
+| * `method`: The fully qualified method name
+* `result = [valueReturned\|exceptionThrown]`: Whether the invocation returned a value or threw an exception
+* `fallback = [applied\|notApplied\|notDefined]`: Whether the fallback method was invoked
+    ** `applied` If fallback was used
+    ** `notApplied` If a fallback is configured but was not used
+    ** `notDefined` If a fallback is not configured.
+| The number of times the method was called. This metric is a `LongCounter`.
+| n/a
+| {mp-tel-2-0-ft-4-1}
+| {mp-tel-2-0}
+
+| ft.retry.calls.total
+| * `method`: The fully qualified method name,
+* `retried = [true\|false]`: Whether any retries occurred
+* `retryResult = [valueReturned\|exceptionNotRetryable\|maxRetriesReached\|maxDurationReached]`: The reason that last attempt to call the method was not retried
+| The number of times the retry logic was run. This value is always equal to once per method call. This metric is a `LongCounter`.
+| n/a
+| {mp-tel-2-0-ft-4-1}
+| {mp-tel-2-0}
+
+| ft.retry.retries.total
+| `method`: The fully qualified method name
+| The number of times the method was retried. This metric is a `LongCounter`.
+| n/a
+| {mp-tel-2-0-ft-4-1}
+| {mp-tel-2-0}
+
+| ft.timeout.executionDuration
+| `method`: The fully qualified method name
+| Histogram of execution times for the method. This metric is a `DoubleHistogram`
+| n/a
+| {mp-tel-2-0-ft-4-1}
+| {mp-tel-2-0}
+
+| ft.timeout.calls.total
+| * `method`: The fully qualified method name
+* `timedOut = [true\|false]`: Whether the method call timed out
+| The number of times the timeout logic was run. This value is typically equal to once per method call. However, it might be zero if the circuit breaker prevents execution or more than once per method call if the method is retried. This metric is a `LongCounter`.
+| n/a
+| {mp-tel-2-0-ft-4-1}
+| {mp-tel-2-0}
+
 | `http.server.request.duration`
 |* `http.request.method`
 * `url.scheme`
@@ -268,7 +376,6 @@ The **Version introduced** column specifies the minimum version of the feature t
 | feature:mpTelemetry[display=MicroProfile Telemetry]
 | feature:mpTelemetry-2.0[display=MicroProfile Telemetry 2.0]
 
-
 | jvm.class.unloaded
 | n/a
 | Number of classes unloaded since JVM start. This metric is a Counter. / ({class})
diff --git a/modules/ROOT/pages/observability.adoc b/modules/ROOT/pages/observability.adoc
index fc71f777fb..a9ca003580 100644
--- a/modules/ROOT/pages/observability.adoc
+++ b/modules/ROOT/pages/observability.adoc
@@ -15,12 +15,14 @@
 
 When applications are observable, operations teams can identify and understand the root causes of bugs, bottlenecks, and other inefficiencies. Open Liberty provides a robust framework for developing observable applications and integrates with numerous third-party monitoring tools.
 
-With MicroProfile Telemetry 2.0 and later, you can manage logs, metrics, and traces in a standardized way by using the OpenTelemetry protocol. For more information, see xref:microprofile-telemetry.adoc[Enable observability with MicroProfile Telemetry].
+With MicroProfile Telemetry 2.0 and later, you can manage logs, metrics, and traces in a standardized way by using the OpenTelemetry protocol. For more information, see xref:microprofile-telemetry.adoc[Collect logs, metrics, and traces with OpenTelemetry].
 
 The following topics provide information to help you develop observable applications with Open Liberty.
 
-xref:prepare-mptelemetry.adoc[Prepare your development environment for MicroProfile Telemetry]::
+////
+xref:prepare-mptelemetry.adoc[Customize your application telemetry with the OpenTelemetry API]::
 Before you manually instrument your code to use MicroProfile Telemetry to collect metrics and traces, you must enable MicroProfile Telemetry in your development environment by editing your runtime configuration. You must also add the OpenTelemetry API and annotations as a dependency on your build path.
+////
 
 xref:custom-mptelemetry-metrics.adoc[Define custom MicroProfile Telemetry metrics]::
 You can use the OpenTelemetry metrics API to define custom metrics in your application code. When you enable the MicroProfile Telemetry feature 2.0 or later, you can then collect and emit these metrics to customize the observability of your application.
@@ -28,8 +30,13 @@ You can use the OpenTelemetry metrics API to define custom metrics in your appli
 xref:telemetry-trace.adoc[Code instrumentation for MicroProfile Telemetry tracing]::
 After you enable MicroProfile Telemetry and configure a trace server, you can instrument tracing in your application code. You can instrument your code automatically, manually, or by using the Java agent.
 
+////
 xref:mptelemetry-logging.adoc[Write logs with MicroProfile Telemetry logging]::
 You can use MicroProfile Telemetry to mange your logs, along with traces and metrics. When you enable the MicroProfile Telemetry feature version 2.0 or later, MicroProfile Telemetry automatically collects any logs that are sent to the `java.util.logging` API.
+////
+
+xref:health-check-microservices.adoc[Health checks for microservices]::
+A health check is a special REST API implementation that you can use to validate the status of a microservice and its dependencies. With MicroProfile Health, microservices can self-check their health and publish their overall status to a defined endpoint.
 
 xref:microservice-observability-metrics.adoc[Microservice observability with MicroProfile metrics]::
 Open Liberty uses MicroProfile Metrics to provide metrics that describe the internal state of many Open Liberty components. MicroProfile Metrics provides a `/metrics` endpoint from which you can access all metrics that are emitted by an Open Liberty server and deployed applications.
@@ -37,8 +44,5 @@ Open Liberty uses MicroProfile Metrics to provide metrics that describe the inte
 xref:micrometer-metrics.adoc[Choose your own monitoring tools with MicroProfile Metrics]::
 The Open Liberty MicroProfile Metrics 5.0 feature uses embedded Micrometer metrics technology to transfer metric data to multiple third-party monitoring systems. Starting in MicroProfile Metrics 5.0, you can instrument your code in a standardized way to visualize metrics results in the monitoring system of your choice.
 
-xref:health-check-microservices.adoc[Health checks for microservices]::
-A health check is a special REST API implementation that you can use to validate the status of a microservice and its dependencies. With MicroProfile Health, microservices can self-check their health and publish their overall status to a defined endpoint.
-
 
 For hands-on tutorials on different observability configurations for Open Liberty, check out our link:/guides/#observability[Observability guides].
diff --git a/modules/ROOT/pages/password-encryption.adoc b/modules/ROOT/pages/password-encryption.adoc
index 61fe3132e3..dd7575680d 100644
--- a/modules/ROOT/pages/password-encryption.adoc
+++ b/modules/ROOT/pages/password-encryption.adoc
@@ -18,7 +18,7 @@
 Open Liberty supports Advanced Encryption Standard (AES) encryption for passwords that are stored in the `server.xml` file.
 When you use this option for protecting passwords in the Open Liberty configuration, understand the limitations to the protection that AES encryption provides.
 
-The Open Liberty `securityUtility encode` command uses AES-256 encryption when the `--encoding` option is set to `aes`. The default value for this option is `xor`. For AES decryption, Open Liberty supports both AES-128 and AES-256.
+The Open Liberty `securityUtility encode` command uses AES-128 encryption when the `--encoding` option is set to `aes`. The default value for this option is `xor`. For AES decryption, Open Liberty supports AES-128.
 
 Encrypting a password in the Open Liberty configuration does not guarantee that the password is secure or protected.
 Encrypting a password means that someone who can see the encrypted password cannot easily recover the password unless they know the encryption key.
diff --git a/modules/ROOT/pages/prepare-mptelemetry.adoc b/modules/ROOT/pages/prepare-mptelemetry.adoc
index 208d89dae1..f01990f248 100644
--- a/modules/ROOT/pages/prepare-mptelemetry.adoc
+++ b/modules/ROOT/pages/prepare-mptelemetry.adoc
@@ -10,7 +10,7 @@
 :seo-description:
 :page-layout: general-reference
 :page-type: general
-= Prepare your development environment for MicroProfile Telemetry
+= Customize your application telemetry with the OpenTelemetry API
 
 Before you manually instrument your code to use MicroProfile Telemetry to collect metrics and traces, you must enable MicroProfile Telemetry in your development environment by editing your runtime configuration. You must also add the OpenTelemetry API and annotations as a dependency on your build path.
 
diff --git a/modules/ROOT/pages/rest-clients.adoc b/modules/ROOT/pages/rest-clients.adoc
index 743ec0a357..5c678c552f 100644
--- a/modules/ROOT/pages/rest-clients.adoc
+++ b/modules/ROOT/pages/rest-clients.adoc
@@ -27,7 +27,9 @@ The template interface that you build with MicroProfile REST Client maps to the
 
 You can use MicroProfile REST Client with Open Liberty by enabling the feature:mpRestClient[display=MicroProfile Rest Client] feature in your `server.xml` file. For more information, see link:/guides/microprofile-rest-client.html[Consuming RESTful services with template interfaces] and link:/guides/microprofile-rest-client-async.html[Consuming RESTful services asynchronously with template interfaces].
 
-If you update your server from an earlier version of the feature:mpRestClient[display=MicroProfile REST Client] to version 3.0, changes in API behavior might require you to update your application code. For more information, see xref:reference:diff/mp-41-50-diff.adoc#rc[Differences between MicroProfile REST Client 3.0 and 2.0].
+If you update your server from a version of the feature:mpRestClient[display=MicroProfile REST Client] earlier than 3.0 to version 3.0 or higher, changes in API behavior might require you to update to your application code. For more information, see xref:reference:diff/mp-41-50-diff.adoc#rc[Differences between MicroProfile REST Client 3.0 and 2.0].
+
+In addition, If you update your server to version 4.0 of the feature:mpRestClient[display=MicroProfile REST Client], see xref:reference:diff/mp-61-70-diff.adoc#rc[Differences between MicroProfile REST Client 4.0 and 3.0].
 
 == Synchronous and asynchronous REST clients
 
diff --git a/modules/ROOT/pages/security-vulnerabilities.adoc b/modules/ROOT/pages/security-vulnerabilities.adoc
index 512e9f656d..5c9ed845bf 100644
--- a/modules/ROOT/pages/security-vulnerabilities.adoc
+++ b/modules/ROOT/pages/security-vulnerabilities.adoc
@@ -28,6 +28,13 @@ The `CWWKF0012I` message uses the word "installed", but it lists features that a
 |===
 |CVE |CVSS score by X-Force® |Vulnerability assessment |Versions affected |Version fixed |Notes
 
+|https://www.cve.org/CVERecord?id=CVE-2024-40094[CVE-2024-40094]
+|5.3
+|Denial of service
+|20.0.0.6 - 24.0.0.11
+|24.0.0.12
+|Affects the feature:mpGraphQL-1.0[] and feature:mpGraphQL-2.0[] features
+
 |https://www.cve.org/CVERecord?id=CVE-2024-7254[CVE-2024-7254]
 |7.5
 |Denial of service
@@ -35,462 +42,462 @@ The `CWWKF0012I` message uses the word "installed", but it lists features that a
 |24.0.0.11
 |Affects the feature:grpc-1.0[] and feature:grpcClient-1.0[] features
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-50314[CVE-2023-50314]
+|http://www.cve.org/CVERecord?id=CVE-2023-50314[CVE-2023-50314]
 |5.3
 |Information disclosure
 |17.0.0.3 - 24.0.0.8
 |24.0.0.9
 |
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-22354[CVE-2024-22354]
+|http://www.cve.org/CVERecord?id=CVE-2024-22354[CVE-2024-22354]
 |7.0
 |XML External Entity (XXE) injection
 |17.0.0.3 - 24.0.0.5
 |24.0.0.6
 |
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-27268[CVE-2024-27268]
+|http://www.cve.org/CVERecord?id=CVE-2024-27268[CVE-2024-27268]
 |5.9
 |Denial of service
 |18.0.0.2 - 24.0.0.4
 |24.0.0.5
 |Affects the feature:servlet-3.1[], feature:servlet-4.0[], feature:servlet-5.0[] and feature:servlet-6.0[] features
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-22353[CVE-2024-22353]
+|http://www.cve.org/CVERecord?id=CVE-2024-22353[CVE-2024-22353]
 |5.9
 |Denial of service
 |17.0.0.3 - 24.0.0.4
 |24.0.0.5
 |Affects the feature:openidConnectClient-1.0[], and feature:socialLogin-1.0[] features
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-25026[CVE-2024-25026]
+|http://www.cve.org/CVERecord?id=CVE-2024-25026[CVE-2024-25026]
 |5.9
 |Denial of service
 |17.0.0.3 - 24.0.0.4
 |24.0.0.5
 |Affects the feature:servlet-3.1[], feature:servlet-4.0[], feature:servlet-5.0[] and feature:servlet-6.0[] features
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-51775[CVE-2023-51775]
+|http://www.cve.org/CVERecord?id=CVE-2023-51775[CVE-2023-51775]
 |7.5
 |Denial of service
 |21.0.0.3 - 24.0.0.3
 |24.0.0.4
 |Affects the feature:openidConnectClient-1.0[], feature:socialLogin-1.0[], feature:mpJwt-1.2[], feature:mpJwt-2.0[], feature:mpJwt-2.1[], feature:jwt-1.0[] features
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-27270[CVE-2024-27270]
+|http://www.cve.org/CVERecord?id=CVE-2024-27270[CVE-2024-27270]
 |4.7
 |Cross-site scripting
 |23.0.0.3 - 24.0.0.3
 |24.0.0.4
 |Affects the feature:servlet-6.0[] feature
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-50312[CVE-2023-50312]
+|http://www.cve.org/CVERecord?id=CVE-2023-50312[CVE-2023-50312]
 |5.3
 |Weaker security
 |17.0.0.3 - 24.0.0.2
 |24.0.0.3
 |
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-44487[CVE-2023-44487]
+|http://www.cve.org/CVERecord?id=CVE-2023-44487[CVE-2023-44487]
 |7.5
 |Denial of service
 |18.0.0.2 - 23.0.0.11
 |23.0.0.12
 |Affects the feature:servlet-3.1[], feature:servlet-4.0[], feature:servlet-5.0[] and feature:servlet-6.0[] features
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-44483[CVE-2023-44483]
+|http://www.cve.org/CVERecord?id=CVE-2023-44483[CVE-2023-44483]
 |6.5
 |Information disclosure
 |17.0.0.3 - 23.0.0.11
 |23.0.0.12
 |Affects the feature:wsSecurity-1.1[], feature:wsSecuritySaml-1.1[] and feature:samlWeb-2.0[] features
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-46158[CVE-2023-46158]
+|http://www.cve.org/CVERecord?id=CVE-2023-46158[CVE-2023-46158]
 |4.9
 |Weaker security
 |23.0.0.9 - 23.0.0.10
 |23.0.0.11
 |Affects the feature:appSecurity-1.0[], feature:appSecurity-2.0[], feature:appSecurity-3.0[], feature:appSecurity-4.0[] and feature:appSecurity-5.0[] features
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-38737[CVE-2023-38737]
+|http://www.cve.org/CVERecord?id=CVE-2023-38737[CVE-2023-38737]
 |5.9
 |Denial of service
 |22.0.0.13 - 23.0.0.7
 |23.0.0.8
 |Affects the feature:restfulWS-3.0[] and feature:restfulWS-3.1[] features
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-28867[CVE-2023-28867]
+|http://www.cve.org/CVERecord?id=CVE-2023-28867[CVE-2023-28867]
 |7.5
 |Denial of service
 |17.0.0.3 - 23.0.0.5
 |23.0.0.6
 |Affects the feature:mpGraphQL-1.0[] and feature:mpGraphQL-2.0[] features
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-24998[CVE-2023-24998]
+|http://www.cve.org/CVERecord?id=CVE-2023-24998[CVE-2023-24998]
 |7.5
 |Denial of service
 |17.0.0.3 - 23.0.0.3
 |23.0.0.4
 |Affects the feature:servlet-3.1[], feature:servlet-4.0[], feature:servlet-5.0[] and feature:servlet-6.0[] features
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-0482[CVE-2023-0482]
+|http://www.cve.org/CVERecord?id=CVE-2023-0482[CVE-2023-0482]
 |5.3
 |Privilege escalation
 |21.0.0.12 - 23.0.0.3
 |23.0.0.4
 |Affects the feature:restfulWS-3.0[] and feature:restfulWS-3.1[] features
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-45787[CVE-2022-45787]
+|http://www.cve.org/CVERecord?id=CVE-2022-45787[CVE-2022-45787]
 |5.5
 |Information disclosure
 |21.0.0.12 - 23.0.0.1
 |23.0.0.2
 |Affects the feature:restfulWS-3.0[] feature
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-46364[CVE-2022-46364]
+|http://www.cve.org/CVERecord?id=CVE-2022-46364[CVE-2022-46364]
 |9.8
 |Server-side request forgery
 |17.0.0.3 - 23.0.0.1
 |23.0.0.2
 |Affects the feature:jaxws-2.2[] feature
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3509[CVE-2022-3509]
+|http://www.cve.org/CVERecord?id=CVE-2022-3509[CVE-2022-3509]
 |5.7
 |Denial of service
 |21.0.0.2 - 22.0.0.12
 |22.0.0.13
 |Affects the feature:grpc-1.0[] and feature:grpcClient-1.0[] features
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3171[CVE-2022-3171]
+|http://www.cve.org/CVERecord?id=CVE-2022-3171[CVE-2022-3171]
 |5.7
 |Denial of service
 |21.0.0.2 - 22.0.0.12
 |22.0.0.13
 |Affects the feature:grpc-1.0[] and feature:grpcClient-1.0[] features
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-37734[CVE-2022-37734]
+|http://www.cve.org/CVERecord?id=CVE-2022-37734[CVE-2022-37734]
 |7.5
 |Denial of service
 |17.0.0.3 - 22.0.0.11
 |22.0.0.12
 |Affects the feature:mpGraphQL-1.0[] and feature:mpGraphQL-2.0[] features
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-24839[CVE-2022-24839]
+|http://www.cve.org/CVERecord?id=CVE-2022-24839[CVE-2022-24839]
 |7.5
 |Denial of service
 |17.0.0.3 - 22.0.0.10
 |22.0.0.11
 |Affects the feature:openid-2.0[] feature
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-34165[CVE-2022-34165]
+|http://www.cve.org/CVERecord?id=CVE-2022-34165[CVE-2022-34165]
 |5.4
 |HTTP header injection
 |17.0.0.3 - 22.0.0.9
 |22.0.0.10
 |
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22476[CVE-2022-22476]
+|http://www.cve.org/CVERecord?id=CVE-2022-22476[CVE-2022-22476]
 |5
 |Identity spoofing
 |17.0.0.3 - 22.0.0.7
 |22.0.0.8
 |Affects the feature:appSecurity-1.0[], feature:appSecurity-2.0[], feature:appSecurity-3.0[] and feature:appSecurity-4.0[] features
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22475[CVE-2022-22475]
+|http://www.cve.org/CVERecord?id=CVE-2022-22475[CVE-2022-22475]
 |7.1
 |Identity spoofing
 |17.0.0.3 - 22.0.0.5
 |22.0.0.6
 |Affects the feature:appSecurity-1.0[], feature:appSecurity-2.0[], feature:appSecurity-3.0[] and feature:appSecurity-4.0[] features
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22393[CVE-2022-22393]
+|http://www.cve.org/CVERecord?id=CVE-2022-22393[CVE-2022-22393]
 |3.1
 |Information disclosure
 |17.0.0.3 - 22.0.0.5
 |22.0.0.6
 |Affects the feature:adminCenter-1.0[] feature
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-39038[CVE-2021-39038]
+|http://www.cve.org/CVERecord?id=CVE-2021-39038[CVE-2021-39038]
 |4.4
 |Clickjacking vulnerability
 |17.0.0.3 - 22.0.0.2
 |22.0.0.3
 |Affects the feature:openapi-3.1[], feature:mpOpenAPI-1.0[], feature:mpOpenAPI-1.1[] and feature:mpOpenAPI-2.0[] features
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-23450[CVE-2021-23450]
+|http://www.cve.org/CVERecord?id=CVE-2021-23450[CVE-2021-23450]
 |9.8
 |Remote code execution
 |17.0.0.3 - 22.0.0.2
 |22.0.0.3
 |Affects the feature:admin-Center-1.0[] feature
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-46708[CVE-2021-46708]
+|http://www.cve.org/CVERecord?id=CVE-2021-46708[CVE-2021-46708]
 |4.3
 |Clickjacking
 |21.0.0.12 - 22.0.0.1
 |22.0.0.2
 |Affects the feature:openapi-3.1[], feature:mpOpenAPI-1.0[], feature:mpOpenAPI-1.1[], feature:mpOpenAPI-2.0[] and feature:mpOpenAPI-3.0[] features
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-25031[CVE-2018-25031]
+|http://www.cve.org/CVERecord?id=CVE-2018-25031[CVE-2018-25031]
 |5.4
 |Spoofing attack
 |21.0.0.12 - 22.0.0.1
 |22.0.0.2
 |Affects the feature:openapi-3.1[], feature:mpOpenAPI-1.0[], feature:mpOpenAPI-1.1[], feature:mpOpenAPI-2.0[] and feature:mpOpenAPI-3.0[] features
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-39031[CVE-2021-39031]
+|http://www.cve.org/CVERecord?id=CVE-2021-39031[CVE-2021-39031]
 |7.5
 |LDAP injection
 |17.0.0.3 - 22.0.0.1
 |22.0.0.2
 |Affects the feature:ldapRegistry-3.0[] feature
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22310[CVE-2022-22310]
+|http://www.cve.org/CVERecord?id=CVE-2022-22310[CVE-2022-22310]
 |4.8
 |Information disclosure
 |21.0.0.10 - 21.0.0.12
 |22.0.0.1
 |Affects the feature:jaxws-2.2[] feature
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-36090[CVE-2021-36090]
+|http://www.cve.org/CVERecord?id=CVE-2021-36090[CVE-2021-36090]
 |7.5
 |Denial of service
 |17.0.0.3 - 21.0.0.9
 |21.0.0.10
 |
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-35517[CVE-2021-35517]
+|http://www.cve.org/CVERecord?id=CVE-2021-35517[CVE-2021-35517]
 |5.5
 |Denial of service
 |17.0.0.3 - 21.0.0.9
 |21.0.0.10
 |
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-29842[CVE-2021-29842]
+|http://www.cve.org/CVERecord?id=CVE-2021-29842[CVE-2021-29842]
 |3.7
 |Information disclosure
 |17.0.0.3 - 21.0.0.9
 |21.0.0.10
 |Affects the feature:federatedRegistry-1.0[] feature
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-26296[CVE-2021-26296]
+|http://www.cve.org/CVERecord?id=CVE-2021-26296[CVE-2021-26296]
 |8.8
 |Cross-site request forgery
 |17.0.0.3 - 21.0.0.3
 |21.0.0.4
 |Affects the feature:jsf-2.2[] and feature:jsf-2.3[] features
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10693[CVE-2020-10693]
+|http://www.cve.org/CVERecord?id=CVE-2020-10693[CVE-2020-10693]
 |5.3
 |Bypass security
 |17.0.0.3 - 20.0.0.10
 |20.0.0.11
 |Affects the feature:beanValidation-2.0[] feature
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-4590[CVE-2020-4590]
+|http://www.cve.org/CVERecord?id=CVE-2020-4590[CVE-2020-4590]
 |5.3
 |Denial of service
 |19.0.0.5 - 20.0.0.9
 |20.0.0.10
 |Affects the feature:oauth-2.0[] and feature:openidConnectServer-1.0[] features
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-4421[CVE-2020-4421]
+|http://www.cve.org/CVERecord?id=CVE-2020-4421[CVE-2020-4421]
 |5
 |Identity spoofing
 |19.0.0.5 - 20.0.0.4
 |20.0.0.5
 |Affects the feature:openidConnectServer-1.0[] feature
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-4329[CVE-2020-4329]
+|http://www.cve.org/CVERecord?id=CVE-2020-4329[CVE-2020-4329]
 |4.3
 |Information disclosure
 |17.0.0.3 - 20.0.0.4
 |20.0.0.5
 |Affects the feature:servlet-3.1[], feature:servlet-4.0[], feature:appSecurity-2.0[], and feature:appSecurity-3.0[] features
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-4303[CVE-2020-4303]
+|http://www.cve.org/CVERecord?id=CVE-2020-4303[CVE-2020-4303]
 |6.1
 |Cross-site scripting
 |17.0.0.3 - 20.0.0.3
 |20.0.0.4
 |Affects the feature:oauth-2.0[], feature:openidConnectClient-1.0[], feature:openidConnectServer-1.0[], and feature:samlWeb-2.0[] features
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-4304[CVE-2020-4304]
+|http://www.cve.org/CVERecord?id=CVE-2020-4304[CVE-2020-4304]
 |6.1
 |Cross-site scripting
 |17.0.0.3 - 20.0.0.3
 |20.0.0.4
 |Affects the feature:oauth-2.0[], feature:openidConnectClient-1.0[], feature:openidConnectServer-1.0[], and feature:samlWeb-2.0[] features
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-17573[CVE-2019-17573]
+|http://www.cve.org/CVERecord?id=CVE-2019-17573[CVE-2019-17573]
 |6.1
 |Cross-site scripting
 |17.0.0.3 - 20.0.0.2
 |20.0.0.3
 |Affects the feature:jaxws-2.2[] feature
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12406[CVE-2019-12406]
+|http://www.cve.org/CVERecord?id=CVE-2019-12406[CVE-2019-12406]
 |5.3
 |Denial of service
 |17.0.0.3 - 20.0.0.1
 |20.0.0.2
 |Affects the feature:jaxrs-2.0[], feature:jaxrs-2.1[], and feature:jaxws-2.2[] features
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-4720[CVE-2019-4720]
+|http://www.cve.org/CVERecord?id=CVE-2019-4720[CVE-2019-4720]
 |7.5
 |Denial of service
 |17.0.0.3 - 20.0.0.1
 |20.0.0.2
 |
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-17495[CVE-2019-17495]
+|http://www.cve.org/CVERecord?id=CVE-2019-17495[CVE-2019-17495]
 |5.3
 |Information disclosure
 |17.0.0.3 - 19.0.0.12
 |20.0.0.1
 |Affects the feature:mpOpenAPI-1.0[], feature:mpOpenAPI-1.1[], and feature:openapi-3.1[] features
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-4441[CVE-2019-4441]
+|http://www.cve.org/CVERecord?id=CVE-2019-4441[CVE-2019-4441]
 |5.3
 |Information disclosure
 |17.0.0.3 - 19.0.0.10
 |19.0.0.11
 |Affects the feature:jsp-2.2[] and feature:jsp-2.3[] features
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3603[CVE-2014-3603]
+|http://www.cve.org/CVERecord?id=CVE-2014-3603[CVE-2014-3603]
 |6.8
 |Spoofing
 |17.0.0.3 - 19.0.0.10
 |19.0.0.11
 |Affects the feature:wsSecurity-1.1[] and feature:samlWeb-2.0[] features
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9518[CVE-2019-9518]
+|http://www.cve.org/CVERecord?id=CVE-2019-9518[CVE-2019-9518]
 |7.5
 |Denial of service
 |17.0.0.3 - 19.0.0.9
 |19.0.0.10
 |Affects the feature:servlet-3.1[] and feature:servlet-4.0[] features
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9517[CVE-2019-9517]
+|http://www.cve.org/CVERecord?id=CVE-2019-9517[CVE-2019-9517]
 |7.5
 |Denial of service
 |17.0.0.3 - 19.0.0.9
 |19.0.0.10
 |Affects the feature:servlet-3.1[] and feature:servlet-4.0[] features
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9515[CVE-2019-9515]
+|http://www.cve.org/CVERecord?id=CVE-2019-9515[CVE-2019-9515]
 |7.5
 |Denial of service
 |17.0.0.3 - 19.0.0.9
 |19.0.0.10
 |Affects the feature:servlet-3.1[] and feature:servlet-4.0[] features
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9514[CVE-2019-9514]
+|http://www.cve.org/CVERecord?id=CVE-2019-9514[CVE-2019-9514]
 |7.5
 |Denial of service
 |17.0.0.3 - 19.0.0.9
 |19.0.0.10
 |Affects the feature:servlet-3.1[] and feature:servlet-4.0[] features
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9513[CVE-2019-9513]
+|http://www.cve.org/CVERecord?id=CVE-2019-9513[CVE-2019-9513]
 |7.5
 |Denial of service
 |17.0.0.3 - 19.0.0.9
 |19.0.0.10
 |Affects the feature:servlet-3.1[] and feature:servlet-4.0[] features
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9512[CVE-2019-9512]
+|http://www.cve.org/CVERecord?id=CVE-2019-9512[CVE-2019-9512]
 |7.5
 |Denial of service
 |17.0.0.3 - 19.0.0.9
 |19.0.0.10
 |Affects the feature:servlet-3.1[] and feature:servlet-4.0[] features
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-4304[CVE-2019-4304]
+|http://www.cve.org/CVERecord?id=CVE-2019-4304[CVE-2019-4304]
 |6.3
 |Bypass security
 |17.0.0.3 - 19.0.0.9
 |19.0.0.10
 |Affects the feature:appSecurity-1.0[] and feature:appSecurity-2.0[] features
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-4305[CVE-2019-4305]
+|http://www.cve.org/CVERecord?id=CVE-2019-4305[CVE-2019-4305]
 |5.3
 |Information disclosure
 |17.0.0.3 - 19.0.0.9
 |19.0.0.10
 |Affects the feature:appSecurity-1.0[] and feature:appSecurity-2.0[] features
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3603[CVE-2014-3603]
+|http://www.cve.org/CVERecord?id=CVE-2014-3603[CVE-2014-3603]
 |6.5
 |Man-in-the-Middle
 |17.0.0.3 - 19.0.0.7
 |19.0.0.8
 |Affects the feature:wsSecurity-1.1[] and feature:samlWeb-2.0[] features
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-4046[CVE-2019-4046]
+|http://www.cve.org/CVERecord?id=CVE-2019-4046[CVE-2019-4046]
 |5.9
 |Denial of service
 |17.0.0.3 - 19.0.0.3
 |19.0.0.4
 |Affects the feature:servlet-3.1[] and feature:servlet-4.0[] features
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1902[CVE-2018-1902]
+|http://www.cve.org/CVERecord?id=CVE-2018-1902[CVE-2018-1902]
 |3.1
 |Spoofing
 |17.0.0.3 - 19.0.0.2
 |19.0.0.3
 |Affects the feature:servlet-3.1[] and feature:servlet-4.0[] features
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1901[CVE-2018-1901]
+|http://www.cve.org/CVERecord?id=CVE-2018-1901[CVE-2018-1901]
 |5.0
 |Privilege escalation
 |17.0.0.3 - 18.0.0.3
 |18.0.0.4
 |Affects the feature:ldapRegistry-3.0[] feature
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-7810[CVE-2014-7810]
+|http://www.cve.org/CVERecord?id=CVE-2014-7810[CVE-2014-7810]
 |5.0
 |Bypass security
 |17.0.0.3 - 18.0.0.3
 |18.0.0.4
 |Affects the feature:jsp-2.2[], feature:jsp-2.3[], and feature:el-3.0[] features
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8039[CVE-2018-8039]
+|http://www.cve.org/CVERecord?id=CVE-2018-8039[CVE-2018-8039]
 |7.5
 |Man-in-the-Middle
 |17.0.0.3 - 18.0.0.2
 |18.0.0.3
 |Affects the feature:jaxws-2.2[], feature:jaxrs-2.0[], and feature:jaxrs-2.1[] features
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1755[CVE-2018-1755]
+|http://www.cve.org/CVERecord?id=CVE-2018-1755[CVE-2018-1755]
 |5.9
 |Information disclosure
 |17.0.0.3 - 18.0.0.2
 |18.0.0.3
 |Affects the feature:jaspic-1.1[] feature
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1683[CVE-2018-1683]
+|http://www.cve.org/CVERecord?id=CVE-2018-1683[CVE-2018-1683]
 |5.9
 |Information disclosure
 |17.0.0.3 - 18.0.0.2
 |18.0.0.3
 |Affects the feature:ejbRemote-3.2[] feature
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12624[CVE-2017-12624]
+|http://www.cve.org/CVERecord?id=CVE-2017-12624[CVE-2017-12624]
 |5.3
 |Denial of service
 |17.0.0.3 - 17.0.0.4
 |18.0.0.1
 |Affects the feature:jaxws-2.2[], feature:jaxrs-2.0[], and feature:jaxrs-2.1[] features
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1788[CVE-2017-1788]
+|http://www.cve.org/CVERecord?id=CVE-2017-1788[CVE-2017-1788]
 |5.3
 |Spoofing
 |17.0.0.3 - 17.0.0.4
 |18.0.0.1
 |Affects any feature that enables security, for example, the feature:appSecurity-2.0[], feature:appSecurity-3.0[], and feature:restConnector-2.0[] features
 
-|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-1000031[CVE-2016-100031]
+|http://www.cve.org/CVERecord?id=CVE-2016-1000031[CVE-2016-100031]
 |9.8
 |Execute code
 |17.0.0.3 - 17.0.0.4
diff --git a/modules/ROOT/pages/send-receive-multipart-jaxrs.adoc b/modules/ROOT/pages/send-receive-multipart-jaxrs.adoc
index c9089d58dd..4a93a4991f 100644
--- a/modules/ROOT/pages/send-receive-multipart-jaxrs.adoc
+++ b/modules/ROOT/pages/send-receive-multipart-jaxrs.adoc
@@ -45,6 +45,7 @@ buildscript {
 }
 ----
 
+
 == Send multipart/form-data parts from Jakarta Restful Web Services resources
 
 One way to send multipart form data in an HTTP request is to use an HTML form. You might create an HTML form for a human user to send file data to a web application. The following example shows an HTML form that sends an HTTP request in three parts that each specifies a particular content type.
diff --git a/modules/ROOT/pages/telemetry-trace.adoc b/modules/ROOT/pages/telemetry-trace.adoc
index e0532f6705..3d05346afd 100644
--- a/modules/ROOT/pages/telemetry-trace.adoc
+++ b/modules/ROOT/pages/telemetry-trace.adoc
@@ -21,7 +21,7 @@ After you enable MicroProfile Telemetry and configure a trace server, you can in
 [#auto]
 == Automatic instrumentation
 
-With automatic instrumentation, you can observe traces without modifying the source code in your applications. All that you need to do is configure runtime as described in xref:microprofile-telemetry.adoc#traces[Configuring Open Liberty to use MicroProfile Telemetry to collect traces]. However, automatic instrumentation is available only for JAX-RS and Jakarta RESTful web service applications.
+With automatic instrumentation, you can observe traces without modifying the source code in your applications. All that you need to do is configure runtime as described in xref:microprofile-telemetry.adoc[Collect logs, metrics, and traces with OpenTelemetry]. However, automatic instrumentation is available only for JAX-RS and Jakarta RESTful web service applications.
 
 In Open Liberty version 23.0.0.11 and later, spans are automatically generated for incoming HTTP requests, including static files, servlets, and JSPs.
 
@@ -30,9 +30,9 @@ In Open Liberty version 23.0.0.11 and later, spans are automatically generated f
 
 Automatic instrumentation is available only for JAX-RS and Jakarta RESTful web service applications. To create spans for other operations, such as database calls, you can add manual instrumentation to the source code for those operations by using the https://www.javadoc.io/doc/io.opentelemetry/opentelemetry-api/1.39.0/io/opentelemetry/api/trace/package-summary.html[OpenTelemetry API].
 
-However, before you manually instrument your code, you must enable MicroProfile Telemetry in your development environment by editing your runtime configuration. You must also add the OpenTelemetry API and annotations as a dependency on your build path. For more information, see xref:prepare-mptelemetry.adoc[Prepare your development environment for MicroProfile Telemetry].
+However, before you manually instrument your code, you must make 3rd party APIs visible in your runtime environment by editing your runtime configuration. For more information, see link:/docs/latest/reference/feature/mpTelemetry-2.0.html#dev[Customize your application telemetry with the OpenTelemetry API].
 
-After you complete those prerequisites, you're ready to instrument your code. The following examples show configuration options with the OpenTelemetry API.
+The following examples show configuration options with the OpenTelemetry API.
 
 - Add extra information, such as the user ID, to the current span. Any information that you add to a span is visible when you look at the traces on your trace server.
 +
diff --git a/modules/ROOT/pages/telemetry-troubleshooting.adoc b/modules/ROOT/pages/telemetry-troubleshooting.adoc
new file mode 100644
index 0000000000..b1e286b992
--- /dev/null
+++ b/modules/ROOT/pages/telemetry-troubleshooting.adoc
@@ -0,0 +1,77 @@
+// Copyright (c) 2024 IBM Corporation and others.
+// Licensed under Creative Commons Attribution-NoDerivatives
+// 4.0 International (CC BY-ND 4.0)
+//   https://creativecommons.org/licenses/by-nd/4.0/
+//
+// Contributors:
+//     IBM Corporation
+//
+:page-description:
+:seo-description:
+:page-layout: general-reference
+:page-type: general
+= Troubleshooting OpenTelemetry
+
+The following information can help you determine the cause of common problems and error messages that are associated with OpenTelemetry logs, metrics, and tracing. To help debug issues with your OpenTelemetry logs, metrics, or traces, you can export this data to the console for analysis.
+
+[#console]
+== Exporting logs, metrics, or traces to the console for debugging purposes
+
+By default, all OpenTelemetry data is exported to the `otlp` exporter. For debugging purposes, you can temporarily change the export destination to the `console.log` file by setting the `otel.< _signal_ >.exporter=console` property at the application or the runtime level.
+
+For example, to send all application and runtime traces to the `console.log` file, you might set the following property in the `bootstrap.properties` file:
+
+[source,properties]
+----
+otel.traces.exporter=console
+----
+
+Similarly, to send all application and runtime logs to the `console.log` file, set the following property in the `bootstrap.properties` file:
+
+[source,properties]
+----
+otel.logs.exporter=console
+----
+
+When you configure the logs exporter to `console`, log records are sent immediately, instead of in batches like they are when the default `otlp` exporter is used.
+
+To send all application and runtime metrics to the `console.log` file, set the following property in the `bootstrap.properties` file:
+
+[source,properties]
+----
+otel.metrics.exporter=console
+----
+
+
+If you enabled OpenTelemetry at the application level and you want to send only the logs, metrics, or traces for a particular application to the console, set the corresponding property in the `microprofile-config.properties` file for the application.
+
+
+== Common problems and error messages
+
+Previous spans are incorrectly shown as current or parent spans::
+
+If the `Scope` instance is not closed correctly, the context and baggage values of previous spans might remain when the next operation runs. Alternatively, the current span might remain and be picked up as the parent of the next operation that runs.
++
+Always close the `Scope` instance when you exit an operation. This configuration stops the span from being current and makes the previous span current again. Use a `try-with-resources` block, which automatically closes the `Scope` instance at the end of the block, as shown in the following example:
++
+[source, java]
+----
+Span span = tracer.spanBuilder("PerformingOperation").startSpan();
+try (Scope scope = span.makeCurrent()) {
+    ...
+} finally {
+    span.end();
+}
+----
+
+You receive the `CWMOT5100I` message that tracing is disabled::
+
+If you enable the `mpTelemetry-1.1` or `mpTelemetry-1.0` feature, you must also set the `otel.sdk.disabled=false` property in any of the configuration sources that are accessible through MicroProfile Config to enable tracing.
+
+You receive the CWMOT5003W message that the application attempted to acquire MicroProfile Telemetry after shut down::
+
+Review the application to see why it attempted to use MicroProfile Telemetry after it shut down. Actions that might trigger MicroProfile Telemetry include calling a method that is annotated with `@WithSpan` or making a request with a JAX-RS Client or MP Rest Client.
+
+You receive either of the CWMOT5006W or CWMOT5007 warning message that conflicting configuration is specified for otel.sdk.disabled::
+
+Specify the settings to enable or disable OpenTelemetry instances by using either environment variables or MicroProfile Config sources, but not both. If you see these warnings, the other MicroProfile Config source to look at is your `server.xml` file.
diff --git a/modules/reference/nav.adoc b/modules/reference/nav.adoc
index da6747fb3b..c22deb5d41 100644
--- a/modules/reference/nav.adoc
+++ b/modules/reference/nav.adoc
@@ -63,6 +63,7 @@ include::reference:partial$platform-nav.adoc[]
   ** xref:javadoc/liberty-javaee7-javadoc.adoc[Java EE 7]
 
 * xref:microprofile-api.adoc[MicroProfile API]
+  ** xref:javadoc/microprofile-7.0-javadoc.adoc[MicroProfile 7.0]
   ** xref:javadoc/microprofile-6.1-javadoc.adoc[MicroProfile 6.1]
   ** xref:javadoc/microprofile-6.0-javadoc.adoc[MicroProfile 6.0]
   ** xref:javadoc/microprofile-5.0-javadoc.adoc[MicroProfile 5.0]
@@ -77,6 +78,7 @@ include::reference:partial$platform-nav.adoc[]
   ** xref:javadoc/microprofile-1.4-javadoc.adoc[MicroProfile 1.4]
   ** xref:javadoc/microprofile-1.3-javadoc.adoc[MicroProfile 1.3]
   ** xref:javadoc/microprofile-1.2-javadoc.adoc[MicroProfile 1.2]
+  ** xref:diff/mp-61-70-diff.adoc[Differences between MicroProfile 7.0 and 6.1]
   ** xref:diff/mp-60-61-diff.adoc[Differences between MicroProfile 6.1 and 6.0]
   ** xref:diff/mp-50-60-diff.adoc[Differences between MicroProfile 6.0 and 5.0]
   ** xref:diff/mp-41-50-diff.adoc[Differences between MicroProfile 5.0 and 4.1]
diff --git a/modules/reference/pages/command/featureUtility-commands.adoc b/modules/reference/pages/command/featureUtility-commands.adoc
index b32deb954b..7a2014c382 100644
--- a/modules/reference/pages/command/featureUtility-commands.adoc
+++ b/modules/reference/pages/command/featureUtility-commands.adoc
@@ -69,6 +69,10 @@ Supported values are `enforce`, `skip`, `all`, and `warn`. If this option is not
 * `all`: Verifies both the Liberty features and the user features. The features that are provided by the Liberty framework and any additional user features or components are checked for integrity.
 * `warn`: Similar to the `all` option, warn also verifies both the Liberty features and user features. This option allows the process to continue, even if some feature signatures cannot be validated. A verification failure does not immediately end the installation process, but it results in a warning message.
 
+|`no_proxy`
+|`http.nonProxyHosts`
+|Requires Open Liberty to use a direct connection instead of a proxy for certain hosts. Specify a list of hostname patterns separated by pipes (`\|`) or commas (`,`). Patterns can start or end with an asterisk (`*`) for wildcards. For any hostname that matches a specified pattern, Open Liberty connects to the host directly instead of going through a proxy.
+
 |`http_proxy`
 |`proxyHost`, `proxyPort`, `proxyUser`, and `proxyPassword`
 a|Configures the outbound HTTP proxy.
diff --git a/modules/reference/pages/command/securityUtility-encode.adoc b/modules/reference/pages/command/securityUtility-encode.adoc
index a40ab9cf8b..6a71e78017 100644
--- a/modules/reference/pages/command/securityUtility-encode.adoc
+++ b/modules/reference/pages/command/securityUtility-encode.adoc
@@ -61,7 +61,7 @@ securityUtility encode [options]
 |Specifies how to encode the password.
 Supported encodings types are `xor`, `aes`, and `hash`.
 The default value for this option is `xor`.
-The `aes` type uses AES-256 encryption.
+The `aes` type uses AES-128 encryption.
 {empty} +
 {empty} +
 You can use the `hash` encoding type to encode passwords for a xref:ROOT:user-registries-application-security.adoc[basic user registry] or passwords for the xref:config/quickStartSecurity.adoc[quickStartSecurity element].
diff --git a/modules/reference/pages/diff/mp-50-60-diff.adoc b/modules/reference/pages/diff/mp-50-60-diff.adoc
index 49da09bffa..a6dac0b168 100644
--- a/modules/reference/pages/diff/mp-50-60-diff.adoc
+++ b/modules/reference/pages/diff/mp-50-60-diff.adoc
@@ -130,7 +130,7 @@ In MicroProfile 6.0, MicroProfile Telemetry 1.0 replaces MicroProfile OpenTracin
 
 === Configuration changes
 
-In addition to replacing the `mpOpenTracing-3.0` feature with the `mpTelemtry-1.0` feature in your `server.xml` file, you must provide configuration to allow the MicroProfile Telemetry feature to connect to your distributed trace service. For more information, see xref:ROOT:microprofile-telemetry.adoc[Enable observability with MicroProfile Telemetry].
+In addition to replacing the `mpOpenTracing-3.0` feature with the `mpTelemtry-1.0` feature in your `server.xml` file, you must provide configuration to allow the MicroProfile Telemetry feature to connect to your distributed trace service. For more information, see xref:ROOT:microprofile-telemetry.adoc[Collect logs, metrics, and traces with OpenTelemetry].
 
 You do not need to package a client for your particular tracing service. MicroProfile Telemetry includes exporters for Zipkin, the OpenTelemetry Protocol (OTLP) (which is used by Jaeger since v1.35), and the older Jaeger protocol. If you need to export to a different service, you can provide a custom exporter by using the link:https://www.javadoc.io/doc/io.opentelemetry/opentelemetry-sdk-extension-autoconfigure-spi/1.19.0/io/opentelemetry/sdk/autoconfigure/spi/traces/ConfigurableSpanExporterProvider.html[ConfigurableSpanExporterProvider service provider interface (SPI)].
 
@@ -188,7 +188,7 @@ Update your application dependencies to remove the OpenTracing API and add the O
 </dependency>
 ----
 
-Just like the MicroProfile OpenTracing 3.0 feature (`mpOpenTracing-3.0`), the MicroProfile Telemetry 1.0 feature (`mpTelemetry-1.0`) feature requires that you xref:ROOT:microprofile-telemetry.adoc#manual[enable third-party APIs] to use the API classes in your application.
+Just like the MicroProfile OpenTracing 3.0 feature (`mpOpenTracing-3.0`), the MicroProfile Telemetry 1.0 feature (`mpTelemetry-1.0`) feature requires that you enable third-party APIs to use the API classes in your application.
 
 The shim converts most calls to the OpenTracing API into calls to the OpenTelemetry API, but it doesn't make the OpenTracing `Tracer` class available for injection.
 To enable injection of the OpenTracing `Tracer` class, you also need to add a CDI Producer Method that uses the shim to provide instances of the class for injection. If CDI discovery is enabled, you can add the following class to your application:
diff --git a/modules/reference/pages/diff/mp-61-70-diff.adoc b/modules/reference/pages/diff/mp-61-70-diff.adoc
new file mode 100644
index 0000000000..ac1f480b7e
--- /dev/null
+++ b/modules/reference/pages/diff/mp-61-70-diff.adoc
@@ -0,0 +1,238 @@
+// Copyright (c) 2024 IBM Corporation and others.
+// Licensed under Creative Commons Attribution-NoDerivatives
+// 4.0 International (CC BY-ND 4.0)
+// https://creativecommons.org/licenses/by-nd/4.0/
+//
+//
+// Contributors:
+// IBM Corporation
+//
+//
+//
+//
+:page-description: MicroProfile 7.0 is a major release. If you are updating your application from using MicroProfile 6.1 features to MicroProfile 7.0 features, the changes in API behavior might require you to update your application code.
+:projectName: Open Liberty
+:page-layout: general-reference
+:page-type: general
+
+
+= Differences between MicroProfile 7.0 and 6.1
+
+MicroProfile 7.0 is a major release. It introduces updated MicroProfile specifications, including MicroProfile Telemetry 2.0, MicroProfile Rest Client 4.0, MicroProfile OpenAPI 4.0, and MicroProfile Fault Tolerance 4.1. 
+
+This release introduces several important changes:
+
+- MicroProfile Metrics 5.1 is no longer part of the MicroProfile umbrella release and now stands as an independent specification.
+- MicroProfile Telemetry 2.0 expands observability by adding support for Logs and Metrics.
+- MicroProfile Rest Client 4.0 uses Jakarta Restful Web Services 3.1 to support multipart form data.
+- MicroProfile OpenAPI 4.0 complies with the OpenAPI 3.1 standards which help ensure compliance with the latest specifications.
+- MicroProfile 7.0 requires Jakarta EE 10 as the minimum version.
+
+
+If you are updating your application from using MicroProfile 6.1 features to using link:https://github.com/eclipse/microprofile/releases/tag/7.0[MicroProfile 7.0] features, the changes in API behavior might require you to update your application code. The following sections provide details about migrating your applications from MicroProfile 6.1 to MicroProfile 7.0:
+
+- <<#mp, Differences between MicroProfile 7.0 and 6.1 umbrella features>>
+- <<#rc, Differences between MicroProfile REST Client 4.0 and 3.0>>
+- <<#openapi, Differences between MicroProfile OpenAPI 4.0 and 3.1>>
+- <<#ft, Differences between Fault Tolerance 4.1 and 4.0>>
+- <<#tm, Differences between Telemetry 2.0 and 1.1>>
+
+
+[#mp]
+== Differences between MicroProfile 7.0 and 6.1 umbrella features
+
+link:https://download.eclipse.org/microprofile/microprofile-7.0/microprofile-spec-7.0.html[MicroProfile 7.0] is a major release that includes backward-incompatible changes. One significant update is the replacement of MicroProfile Metrics with MicroProfile Telemetry 2.0, which offers Metrics capabilities in addition to support for logs and tracing.
+
+If you are using MicroProfile Metrics from MicroProfile 6.1, include the following configuration in your `server.xml` file when you upgrade to MicroProfile 7.0:
+
+[source,xml]
+----
+<feature>mpMetrics-5.1</feature>
+----
+
+If your application does not use any APIs from MicroProfile Metrics, no migration effort is needed. You can instead use feature:mpTelemetry-2.0[display=MicroProfile Telemetry metrics].
+
+In Open Liberty, the feature:jakartaee-10.0[display=Jakarta EE 10 Core Profile] features are automatically included with the `microProfile-7.0` feature to provide a smoother upgrade experience from `microProfile-6.1`.
+
+
+
+[#rc]
+== Differences between MicroProfile REST Client 4.0 and 3.0
+
+With the release of the feature:mpRestClient-4.0[display=MicroProfile REST Client 4.0], the underlying MicroProfile REST Client implementation for Open Liberty is now compatible with Jakarta EE 10 and is designed to tolerate Jakarta EE 11.
+
+The following sections provide details about changes in behavior between the feature:mpRestClient-3.0[display=MicroProfile Rest Client 3.0] and feature:mpRestClient-4.0[display=MicroProfile Rest Client 4.0] features.
+
+
+=== Client creation without URI
+
+You no longer need to create a `URI` object themselves to create a Client instance; instead, you can pass a `String` directly.
+
+[source,java]
+----
+RestClientBuilder.newBuilder()
+                 .baseUri("http://example.com")
+                 .build(SomeClient.class)
+----
+
+
+=== Set HTTP Headers on a per instance basis
+
+You can now set HTTP headers for each Client instance by using the new `RestClientBuilder.header(String, Object)` method.
+
+[source,java]
+----
+RestClientBuilder.newBuilder()
+                 .baseUri(someURI or String)
+                 .header("Some-Header", headerValueObj)
+                 .build(SomeClient.class)
+----
+
+=== Processing multipart data
+
+The link:https://download.eclipse.org/microprofile/microprofile-rest-client-4.0/microprofile-rest-client-spec-4.0.html#_processing_multipart_data[MicroProfile Rest Client 4.0 specification] includes information and example code for processing multipart data, introduced as part of RESTful Web Services version 3.1 in EE10.
+
+
+[#openapi]
+== Differences between MicroProfile OpenAPI 4.0 and 3.1
+
+=== OpenAPI version updated to 3.1
+
+The OpenAPI document is now generated in OpenAPI 3.1 format by default, an update from OpenAPI 3.0 in `mpOpenAPI-3.1`.
+
+OpenAPI 3.1 introduces the ability to capture more detail, including the use of the full JSON Schema (2020-12 draft) for describing data objects. It also adds support for documenting webhooks and for indicating that an API uses mutual TLS for authentication. For more information, see the link:https://github.com/OAI/OpenAPI-Specification/releases/tag/3.1.0[OpenAPI 3.1.0 release notes].
+
+New APIs and annotation parameters are added to MicroProfile OpenAPI 4.0 to allow users to take advantage of the new OpenAPI 3.1 features. For more information on the new APIs, see the link:https://download.eclipse.org/microprofile/microprofile-open-api-4.0.2/microprofile-openapi-spec-4.0.2.html#release_notes_40[MicroProfile OpenAPI 4.0 release notes].
+
+If you use the new APIs and annotations that correspond to OpenAPI 3.1 features, the additional information they provide is not included if you configure the MicroProfile OpenAPI 4.0 feature to generate OpenAPI 3.0 documents.
+
+However, these changes mean that OpenAPI 3.1 is not fully compatible with earlier versions, such as OpenAPI 3.0, and existing tools might not work with it. To maintain compatibility with existing tools, you can configure `mpOpenAPI-4.0` to produce OpenAPI 3.0 documentation. For more information, see link:/docs/latest/reference/feature/mpOpenAPI-4.0.html#apiversion[Selecting the OpenAPI specification version].
+
+=== All deployed applications are documented by default
+In this update, all deployed applications are included in the OpenAPI documentation by default. In previous versions of MicroProfile OpenAPI, only the first module of the first deployed application was documented by default.
+
+You can control which applications are included in the documentation by using the following configuration:
+
+[source,xml]
+----
+<mpOpenAPI>
+  <includeApplication>application1</includeApplication>
+  <includeApplication>application2</includeApplication>
+</mpOpenAPI>
+----
+
+For more information on this configuration, see feature:mpOpenAPI-4.0[display=MicroProfile OpenAPI 4.0] feature.
+
+
+
+[#ft]
+== Differences between Fault Tolerance 4.1 and 4.0
+
+feature:mpFaultTolerance-4.1[display=MicroProfile Fault Tolerance 4.1], an update to version 4.0, introduces integration with feature:mpTelemetry-2.0[display=MicroProfile Telemetry 2.0]. This feature allows Fault Tolerance to export metrics directly to MicroProfile Telemetry. The existing integration with feature:mpMetrics-5.1[display=MicroProfile Metrics] remains unchanged.
+
+For integration between MicroProfile Fault Tolerance and MicroProfile Telemetry, you must enable both MicroProfile Fault Tolerance 4.1 and MicroProfile Telemetry 2.0. When both features are enabled, MicroProfile Fault Tolerance can automatically export metrics to MicroProfile Telemetry.
+
+[source,xml]
+----
+<feature>mpFaultTolerance-4.1</feature>
+<feature>mpTelemetry-2.0</feature>
+----
+
+For more information on configuring MicroProfile Telemetry to export metrics, see xref:ROOT:microprofile-telemetry.adoc#global[Collecting and exporting logs, metrics, and traces with OpenTelemetry].
+
+If MicroProfile Fault Tolerance is enabled alongside both MicroProfile Telemetry and MicroProfile Metrics, Fault Tolerance can export metrics to both MicroProfile Telemetry and MicroProfile Metrics.
+
+The following table provides a comparison of the metric types in MicroProfile Metrics and MicroProfile Telemetry. It highlights the differences in data representation and metric types across both specifications.
+
+.Comparison of Metric Types between MicroProfile Metrics and MicroProfile Telemetry
+[cols="1,1,1", options="header"]
+|===
+|Name |Type in MicroProfile Metrics |Type in MicroProfile Telemetry
+
+|`ft.invocations.total`
+|`Counter`
+|`Counter` (provides a long value)
+
+|`ft.retry.calls.total`
+|`Counter`
+|`Counter` (provides a long value)
+
+|`ft.retry.retries.total`
+|`Counter`
+|`Counter` (provides a long value)
+
+|`ft.timeout.calls.total`
+|`Counter`
+|`Counter` (provides a long value)
+
+|`ft.circuitbreaker.calls.total`
+|`Counter`
+|`Counter` (provides a long value)
+
+|`ft.circuitbreaker.state.total`
+|`Gauge<Long>`
+|`Counter` (provides a long value)
+
+|`ft.circuitbreaker.opened.total`
+|`Counter`
+|`Counter` (provides a long value)
+
+|`ft.bulkhead.calls.total`
+|`Counter`
+|`Counter` (provides a long value)
+
+|`ft.bulkhead.executionsRunning`
+|`Gauge<Long>`
+|`UpDownCounter` (provides a long value)
+
+|`ft.bulkhead.executionsWaiting`
+|`Gauge<Long>`
+|`UpDownCounter` (provides a long value)
+|===
+
+
+
+The following table compares histogram metrics in MicroProfile Metrics and MicroProfile Telemetry. It highlights the differences in metric types, units, and bucket boundaries. These details help you to understand the changes that are needed when you move between the two frameworks.
+
+.Comparison between Histogram Metrics in mpMetrics and mpTelemetry
+[cols="1,1,1,1,1", options="header"]
+|===
+|Name |Type in mpMetrics |Unit in mpMetrics |Type in mpTelemetry |Unit in mpTelemetry
+
+|`ft.timeout.executionDuration`
+|`Histogram`
+|Nanoseconds
+|A Histogram that records `double` values with explicit bucket boundaries `[ 0.005, 0.01, 0.025, 0.05, 0.075, 0.1, 0.25, 0.5, 0.75, 1, 2.5, 5, 7.5, 10 ]`
+|Seconds
+
+|`ft.bulkhead.runningDuration`
+|`Histogram`
+|Nanoseconds
+|A Histogram that records `double` values with explicit bucket boundaries `[ 0.005, 0.01, 0.025, 0.05, 0.075, 0.1, 0.25, 0.5, 0.75, 1, 2.5, 5, 7.5, 10 ]`
+|Seconds
+
+|`ft.bulkhead.waitingDuration`
+|`Histogram`
+|Nanoseconds
+|A Histogram that records `double` values with explicit bucket boundaries `[ 0.005, 0.01, 0.025, 0.05, 0.075, 0.1, 0.25, 0.5, 0.75, 1, 2.5, 5, 7.5, 10 ]`
+|Seconds
+|===
+
+
+[#tm]
+== Differences between MicroProfile Telemetry 2.0 and 1.1
+
+feature:mpTelemetry-2.0[display=MicroProfile Telemetry 2.0] is an enhancement to MicroProfile Telemetry 1.1, incorporating OpenTelemetry SDK version 1.39. In the earlier version, only traces were be collected and exported. The updated feature now includes the ability to collect and export metrics and logs. Specifically, the following enhancements are provided:
+
+* Access to the OpenTelemetry Metrics API
+* HTTP metrics
+* JVM runtime environment metrics
+* Runtime-level logs
+* Application logs
+
+MicroProfile Telemetry 2.0 provides runtime-level telemetry. To enable this feature, add the MicroProfile Telemetry feature to your `server.xml` file and enable the OpenTelemetry SDK by using system properties or environment variables. Once the feature is enabled, you can configure how MicroProfile Telemetry collects and exports traces, metrics, and logs. This function differs from MicroProfile Telemetry 1.1, which provided full support through MicroProfile Config for configuration.
+
+If you do not use system properties or environment variables for configuration, runtime-level metrics and logs cannot be collected. Using other available MicroProfile Config properties cannot enable the collection of these metrics and logs.
+
+For more information on OpenTelemetry, see xref:ROOT:microprofile-telemetry.adoc[Collecting and exporting logs, metrics, and traces with OpenTelemetry].
+
diff --git a/modules/reference/pages/feature/microProfile-7.0/description.adoc b/modules/reference/pages/feature/microProfile-7.0/description.adoc
new file mode 100644
index 0000000000..f130045dce
--- /dev/null
+++ b/modules/reference/pages/feature/microProfile-7.0/description.adoc
@@ -0,0 +1 @@
+If you are updating your application from using MicroProfile 6.1 features to using MicroProfile 7.0 features, changes in API behavior might require you to update your application code. For more information, see xref:diff/mp-61-70-diff.adoc[Differences between MicroProfile 7.0 and 6.1].
diff --git a/modules/reference/pages/feature/mpOpenAPI-2.0/examples.adoc b/modules/reference/pages/feature/mpOpenAPI-2.0/examples.adoc
index 222ae3fed3..a70545021b 100644
--- a/modules/reference/pages/feature/mpOpenAPI-2.0/examples.adoc
+++ b/modules/reference/pages/feature/mpOpenAPI-2.0/examples.adoc
@@ -1,37 +1,65 @@
 
-== Examples
-
 === Configure OpenAPI documentation for a multi-module application
 
 // This example only applies to 2.0 forward, and so the file and directory must be manually copied and applied to any new versions. Copy the directory and file and change the directory name to reflect the new feature version, for example `mpOpenAPI-3.2`.
 
-You can specify xref:ROOT:external-configuration.adoc[MicroProfile Config] properties to configure the Microprofile OpenAPI feature to merge OpenAPI documentation for multiple applications or modules into a single document.
+By default, only the first module of the first deployed application is included in the OpenAPI documentation. However, you can configure the MicroProfile OpenAPI feature to merge the OpenAPI documentation for multiple applications or modules into a single document.
+
+For example, the following configuration is for the `sample_app` application, which consists of an `EAR` file containing five web modules.
+
+[source,xml]
+----
+<mpOpenAPI>
+  <includeApplication>all</includeApplication>
+  <excludeModule>sample_app/module-3</excludeModule>
+  <excludeModule>sample_app/module-5</excludeModule>
+  <info title="A multi-module sample application"
+        description="This is a sample application."
+        version="2.0.1"
+        termsOfService="http://example.com/sample_app/terms"
+        contactName="API Support"
+        contactUrl="http://www.example.com/sample_app/support"
+        contactEmail="sample_app_support@example.com"
+        licenseName="License 2.0"
+        licenseUrl="https://www.example.org/licenses/LICENSE-2.0.html"
+        />
+</mpOpenAPI>
+----
+
+- The `<includeApplication>` element specifies that all applications are included in the final OpenAPI document.
+
+- The `<excludeModule>` elements exclude the `module-3` and `module-5` web modules.
+
+- The `<info>` element sets the info section for the final OpenAPI document, which documents web modules 1, 2, and 4.
 
-In the following `microprofile-config.properties` file example, an OpenAPI document is configured for the `sample_app` application, which consists of an `EAR` file with five web modules.
+=== Naming applications and modules   
 
-[source,java]
+- The application name is determined by the value of the `name` attribute when the application is deployed in `server.xml` using `application`, `webApplication`, or `enterpriseApplication`. For example:
++
+[source,xml]
 ----
-mp.openapi.extensions.liberty.merged.include=all
-mp.openapi.extensions.liberty.merged.exclude=sample_app/module-3,sample_app/module-5
-mp.openapi.extensions.liberty.merged.info=
-{
-  "title": "A multi-module sample application",
-  "description": "This is a sample application.",
-  "termsOfService": "http://example.com/sample_app/terms",
-  "contact": {
-    "name": "API Support",
-    "url": "http://www.example.com/sample_app/support",
-    "email": "sample_app_support@example.com"
-  },
-  "license": {
-    "name": "License 2.0",
-    "url": "https://www.example.org/licenses/LICENSE-2.0.html"
-  },
-  "version": "2.0.1"
-}
+<webApplication name="application1" location="application1-v1.war" />
 ----
-* The `mp.openapi.extensions.liberty.merged.include` property specifies that all five modules are included in the final OpenAPI document.
-* The `mp.openapi.extensions.liberty.merged.exclude` overrides the `mp.openapi.extensions.liberty.merged.include` property to exclude the `module-3` and `module-5` web modules.
-* The `mp.openapi.extensions.liberty.merged.info` property sets the `info` section for the final OpenAPI document, which documents web modules 1, 2, and 4.
++
+If the application is deployed in the `dropins` directory or if the `name` attribute is not specified, the name defaults to the archive filename with the extension removed.
++
+- The module name is specified in the web module's `web.xml` file. If there is no `web.xml` file or if it does not specify a name, the module name defaults to the filename with the extension removed.
+
+=== Override the info section in the OpenAPI document
+
+You can also override the `info` section of the OpenAPI document using the following configuration:
+
+[source,xml]
+----
+<mpOpenAPI>
+  <info title="Example API"
+        version="1.0"
+        description="This is an example API"/>
+</mpOpenAPI>
+----
+
+Overriding the `info` section is useful for documenting multiple modules or applications. Without an override, the `info` section can be replaced with a standard version which indicates that documentation from several modules was merged.
 
 For more information, see xref:ROOT:documentation-openapi.adoc#multi-module[Multiple application and multi-module application support with MicroProfile OpenAPI]
+
+
diff --git a/modules/reference/pages/feature/mpOpenAPI-3.0/examples.adoc b/modules/reference/pages/feature/mpOpenAPI-3.0/examples.adoc
index 222ae3fed3..e4162cd726 100644
--- a/modules/reference/pages/feature/mpOpenAPI-3.0/examples.adoc
+++ b/modules/reference/pages/feature/mpOpenAPI-3.0/examples.adoc
@@ -1,37 +1,63 @@
 
-== Examples
-
 === Configure OpenAPI documentation for a multi-module application
 
-// This example only applies to 2.0 forward, and so the file and directory must be manually copied and applied to any new versions. Copy the directory and file and change the directory name to reflect the new feature version, for example `mpOpenAPI-3.2`.
+// This example applies only to versions 2.0-3.1.
+
+Only the first module of the first deployed application is included in the OpenAPI documentation by default. However, you can configure the MicroProfile OpenAPI feature to merge the OpenAPI documentation for multiple applications or modules into a single document.
+
+For example, the following configuration is for the `sample_app` application, which consists of an `EAR` file containing five web modules.
+
+[source,xml]
+----
+<mpOpenAPI>
+  <includeApplication>all</includeApplication>
+  <excludeModule>sample_app/module-3</excludeModule>
+  <excludeModule>sample_app/module-5</excludeModule>
+  <info title="A multi-module sample application"
+        description="This is a sample application."
+        version="2.0.1"
+        termsOfService="http://example.com/sample_app/terms"
+        contactName="API Support"
+        contactUrl="http://www.example.com/sample_app/support"
+        contactEmail="sample_app_support@example.com"
+        licenseName="License 2.0"
+        licenseUrl="https://www.example.org/licenses/LICENSE-2.0.html"
+        />
+</mpOpenAPI>
+----
+
+- The `includeApplication` element specifies that all applications are included in the final OpenAPI document.
+
+- The `excludeModule` elements exclude the `module-3` and `module-5` web modules.
+
+- The `info` element sets the info section for the final OpenAPI document, which documents web modules 1, 2, and 4.
+
+==== Naming applications and modules
+
+- The application name is determined by the value of the `name` attribute when the application is deployed in `server.xml` using `application`, `webApplication`, or `enterpriseApplication`. For example:
++
+[source,xml]
+----
+<webApplication name="application1" location="application1-v1.war" />
+----
++
+If the application is deployed in the `dropins` directory or if the `name` attribute is not specified, the name defaults to the archive filename with the extension removed.
++
+- The module name is specified in the web module's `web.xml` file. If there is no `web.xml` file or if it does not specify a name, the module name defaults to the filename with the extension removed.
+
+For more information, see xref:ROOT:documentation-openapi.adoc#multi-module[Multiple application and multi-module application support with MicroProfile OpenAPI].
 
-You can specify xref:ROOT:external-configuration.adoc[MicroProfile Config] properties to configure the Microprofile OpenAPI feature to merge OpenAPI documentation for multiple applications or modules into a single document.
+=== Override the info section in the OpenAPI document
 
-In the following `microprofile-config.properties` file example, an OpenAPI document is configured for the `sample_app` application, which consists of an `EAR` file with five web modules.
+You can override the `info` section of the OpenAPI document specifying the `info` element within the `mpOpenAPI` element:
 
-[source,java]
+[source,xml]
 ----
-mp.openapi.extensions.liberty.merged.include=all
-mp.openapi.extensions.liberty.merged.exclude=sample_app/module-3,sample_app/module-5
-mp.openapi.extensions.liberty.merged.info=
-{
-  "title": "A multi-module sample application",
-  "description": "This is a sample application.",
-  "termsOfService": "http://example.com/sample_app/terms",
-  "contact": {
-    "name": "API Support",
-    "url": "http://www.example.com/sample_app/support",
-    "email": "sample_app_support@example.com"
-  },
-  "license": {
-    "name": "License 2.0",
-    "url": "https://www.example.org/licenses/LICENSE-2.0.html"
-  },
-  "version": "2.0.1"
-}
+<mpOpenAPI>
+  <info title="Example API"
+        version="1.0"
+        description="This is an example API"/>
+</mpOpenAPI>
 ----
-* The `mp.openapi.extensions.liberty.merged.include` property specifies that all five modules are included in the final OpenAPI document.
-* The `mp.openapi.extensions.liberty.merged.exclude` overrides the `mp.openapi.extensions.liberty.merged.include` property to exclude the `module-3` and `module-5` web modules.
-* The `mp.openapi.extensions.liberty.merged.info` property sets the `info` section for the final OpenAPI document, which documents web modules 1, 2, and 4.
 
-For more information, see xref:ROOT:documentation-openapi.adoc#multi-module[Multiple application and multi-module application support with MicroProfile OpenAPI]
+Overriding the `info` section is useful for documenting multiple modules or applications. Without an override, the `info` section is a standard version that indicates that documentation from several modules was merged.
diff --git a/modules/reference/pages/feature/mpOpenAPI-3.1/examples.adoc b/modules/reference/pages/feature/mpOpenAPI-3.1/examples.adoc
index 222ae3fed3..2e21d22b24 100644
--- a/modules/reference/pages/feature/mpOpenAPI-3.1/examples.adoc
+++ b/modules/reference/pages/feature/mpOpenAPI-3.1/examples.adoc
@@ -1,37 +1,63 @@
 
-== Examples
-
 === Configure OpenAPI documentation for a multi-module application
 
-// This example only applies to 2.0 forward, and so the file and directory must be manually copied and applied to any new versions. Copy the directory and file and change the directory name to reflect the new feature version, for example `mpOpenAPI-3.2`.
+// This example applies only to versions 2.0-3.1.
+
+Only the first module of the first deployed application is included in the OpenAPI documentation by default. However, you can configure the MicroProfile OpenAPI feature to merge the OpenAPI documentation for multiple applications or modules into a single document.
+
+For example, the following configuration is for the `sample_app` application, which consists of an `EAR` file containing five web modules.
+
+[source,xml]
+----
+<mpOpenAPI>
+  <includeApplication>all</includeApplication>
+  <excludeModule>sample_app/module-3</excludeModule>
+  <excludeModule>sample_app/module-5</excludeModule>
+  <info title="A multi-module sample application"
+        description="This is a sample application."
+        version="2.0.1"
+        termsOfService="http://example.com/sample_app/terms"
+        contactName="API Support"
+        contactUrl="http://www.example.com/sample_app/support"
+        contactEmail="sample_app_support@example.com"
+        licenseName="License 2.0"
+        licenseUrl="https://www.example.org/licenses/LICENSE-2.0.html"
+        />
+</mpOpenAPI>
+----
+
+- The `includeApplication` element specifies that all applications are included in the final OpenAPI document.
 
-You can specify xref:ROOT:external-configuration.adoc[MicroProfile Config] properties to configure the Microprofile OpenAPI feature to merge OpenAPI documentation for multiple applications or modules into a single document.
+- The `excludeModule` elements exclude the `module-3` and `module-5` web modules.
 
-In the following `microprofile-config.properties` file example, an OpenAPI document is configured for the `sample_app` application, which consists of an `EAR` file with five web modules.
+- The `info` element sets the info section for the final OpenAPI document, which documents web modules 1, 2, and 4.
 
-[source,java]
+==== Naming applications and modules
+
+- The application name is determined by the value of the `name` attribute when the application is deployed in `server.xml` using `application`, `webApplication`, or `enterpriseApplication`. For example:
++
+[source,xml]
 ----
-mp.openapi.extensions.liberty.merged.include=all
-mp.openapi.extensions.liberty.merged.exclude=sample_app/module-3,sample_app/module-5
-mp.openapi.extensions.liberty.merged.info=
-{
-  "title": "A multi-module sample application",
-  "description": "This is a sample application.",
-  "termsOfService": "http://example.com/sample_app/terms",
-  "contact": {
-    "name": "API Support",
-    "url": "http://www.example.com/sample_app/support",
-    "email": "sample_app_support@example.com"
-  },
-  "license": {
-    "name": "License 2.0",
-    "url": "https://www.example.org/licenses/LICENSE-2.0.html"
-  },
-  "version": "2.0.1"
-}
+<webApplication name="application1" location="application1-v1.war" />
 ----
-* The `mp.openapi.extensions.liberty.merged.include` property specifies that all five modules are included in the final OpenAPI document.
-* The `mp.openapi.extensions.liberty.merged.exclude` overrides the `mp.openapi.extensions.liberty.merged.include` property to exclude the `module-3` and `module-5` web modules.
-* The `mp.openapi.extensions.liberty.merged.info` property sets the `info` section for the final OpenAPI document, which documents web modules 1, 2, and 4.
++
+If the application is deployed in the `dropins` directory or if the `name` attribute is not specified, the name defaults to the archive filename with the extension removed.
++
+- The module name is specified in the web module's `web.xml` file. If there is no `web.xml` file or if it does not specify a name, the module name defaults to the filename with the extension removed.
 
 For more information, see xref:ROOT:documentation-openapi.adoc#multi-module[Multiple application and multi-module application support with MicroProfile OpenAPI]
+
+=== Override the info section in the OpenAPI document
+
+You can override the `info` section of the OpenAPI document specifying the `info` element within the `mpOpenAPI` element:
+
+[source,xml]
+----
+<mpOpenAPI>
+  <info title="Example API"
+        version="1.0"
+        description="This is an example API"/>
+</mpOpenAPI>
+----
+
+Overriding the `info` section is useful for documenting multiple modules or applications. Without an override, the `info` section is a standard version that indicates that documentation from several modules was merged.
diff --git a/modules/reference/pages/feature/mpOpenAPI-4.0/examples.adoc b/modules/reference/pages/feature/mpOpenAPI-4.0/examples.adoc
new file mode 100644
index 0000000000..8f7eb8458b
--- /dev/null
+++ b/modules/reference/pages/feature/mpOpenAPI-4.0/examples.adoc
@@ -0,0 +1,73 @@
+
+[#mm]
+=== Configure OpenAPI documentation for a multi-module application
+
+// This example only applies to 4.0 forward, and so the file and directory must be manually copied and applied to any new versions. Copy the directory and file and change the directory name to reflect the new feature version, for example `mpOpenAPI-4.1`.
+
+In MicroProfile OpenAPI 4.0 and later, all deployed applications and modules are included in the OpenAPI documentation by default. However, you can configure which applications and modules are included.
+
+For example, the following configuration is for the `sample_app` application, which consists of an `EAR` file containing five web modules.
+
+[source,xml]
+----
+<mpOpenAPI>
+  <excludeModule>sample_app/module-3</excludeModule>
+  <excludeModule>sample_app/module-5</excludeModule>
+  <info title="A multi-module sample application"
+        description="This is a sample application."
+        version="2.0.1"
+        termsOfService="http://example.com/sample_app/terms"
+        contactName="API Support"
+        contactUrl="http://www.example.com/sample_app/support"
+        contactEmail="sample_app_support@example.com"
+        licenseName="License 2.0"
+        licenseUrl="https://www.example.org/licenses/LICENSE-2.0.html"
+        />
+</mpOpenAPI>
+----
+
+- The `excludeModule` elements exclude the `module-3` and `module-5` web modules.
+
+- The `info` element sets the info section for the final OpenAPI document, which documents web modules 1, 2, and 4.
+
+==== Naming applications and modules
+
+- The application name is determined by the value of the `name` attribute when the application is deployed in `server.xml` using `application`, `webApplication`, or `enterpriseApplication`. For example:
++
+[source,xml]
+----
+<webApplication name="application1" location="application1-v1.war" />
+----
++
+If the application is deployed in the `dropins` directory or if the `name` attribute is not specified, the name defaults to the archive filename without the file extension.
++
+- The module name is specified in the web module's `web.xml` file. If no `web.xml` file exists or if it does not specify a name, the module name defaults to the file name without the file extension.
+
+For more information, see xref:ROOT:documentation-openapi.adoc#multi-module[Multiple application and multi-module application support with MicroProfile OpenAPI].
+
+
+=== Override the info section in the OpenAPI document
+
+You can override the `info` section of the OpenAPI document specifying the `info` element within the `mpOpenAPI` element:
+
+[source,xml]
+----
+<mpOpenAPI>
+  <info title="Example API"
+        version="1.0"
+        description="This is an example API"/>
+</mpOpenAPI>
+----
+
+Overriding the `info` section is useful for documenting multiple modules or applications. Without an override, the `info` section is a standard version that indicates that documentation from several modules was merged.
+
+[#apiversion]
+=== Selecting the OpenAPI specification version
+If you are using a feature that supports more than one version of the OpenAPI specification, you can switch between versions with configuration. You might need to do this if you or your users use tools or libraries that don't yet support a newer version of the OpenAPI specification.
+
+For example, `mpOpenAPI-4.0` defaults to OpenAPI 3.1, but you can specify the following configuration to set it to OpenAPI 3.0.
+
+[source,xml]
+----
+<mpOpenAPI openAPIVersion="3.0"/>
+----
diff --git a/modules/reference/pages/feature/mpTelemetry/description.adoc b/modules/reference/pages/feature/mpTelemetry-1.0/description.adoc
similarity index 59%
rename from modules/reference/pages/feature/mpTelemetry/description.adoc
rename to modules/reference/pages/feature/mpTelemetry-1.0/description.adoc
index 37849acb52..6a45a48c28 100644
--- a/modules/reference/pages/feature/mpTelemetry/description.adoc
+++ b/modules/reference/pages/feature/mpTelemetry-1.0/description.adoc
@@ -1,3 +1 @@
 For information about migrating from MicroProfile Open Tracing to MicroProfile Open Telemetry, see xref:diff/mp-50-60-diff.adoc#telemetry[Differences between MicroProfile Telemetry 1.0 and MicroProfile OpenTracing 3.0].
-
-For information about configuring MicroProfile Telemetry, see xref:ROOT:microprofile-telemetry.adoc[Enable observability with MicroProfile Telemetry].
diff --git a/modules/reference/pages/feature/mpTelemetry-2.0/description.adoc b/modules/reference/pages/feature/mpTelemetry-2.0/description.adoc
new file mode 100644
index 0000000000..ceb7042f4c
--- /dev/null
+++ b/modules/reference/pages/feature/mpTelemetry-2.0/description.adoc
@@ -0,0 +1 @@
+MicroProfile Telemetry 2.0 is compatible with multiple versions of the feature:microprofile[display=MicroProfile umbrella feature]. It is automatically enabled when you enable `microprofile-6.1` or `microprofile-7.0`. However, it also works with `microprofile-5.0`, `microprofile-4.1`, or `microprofile-1.4` if you separately enable it alongside any of those features.
diff --git a/modules/reference/pages/feature/mpTelemetry-2.0/examples.adoc b/modules/reference/pages/feature/mpTelemetry-2.0/examples.adoc
index d048f3e3e1..7098549d39 100644
--- a/modules/reference/pages/feature/mpTelemetry-2.0/examples.adoc
+++ b/modules/reference/pages/feature/mpTelemetry-2.0/examples.adoc
@@ -1,17 +1,43 @@
 == Examples
 
+=== Enable OpenTelemetry
+
+To enable OpenTelemetry for Open Liberty, in addition to enabling the MicroProfile Telemetry feature, you must also set the `otel.sdk.disabled=false` system property in one of the valid configuration sources. Depending on your application scenario, you can set this property at the runtime level or the application level. For more information, see xref:ROOT:microprofile-telemetry.adoc#global[Collecting and exporting logs, metrics, and traces with OpenTelemetry].
+
+The following example demonstrates how to enable OpenTelemetry at the runtime level by setting the property in your `bootstrap.properties` file:
+
+----
+otel.sdk.disabled=false
+----
+
+When you enable the MicroProfile Telemetry feature and set this property, your system is ready to collect and export logs, metrics, and traces.
+
 [#logs]
 === Collect logs from a specified source
 
-To enable the MicroProfile Telemetry feature to collect logs from different sources in the Open Liberty runtime environment, configure the `source` attribute for the `mpTelemetry` element with a comma-separated list of comma-separated log sources.
+To enable the MicroProfile Telemetry feature to collect logs from different sources in the Open Liberty runtime environment, configure the `source` attribute for the `mpTelemetry` element with a comma-separated list of log sources.
 
 [source,xml]
 ----
 <mpTelemetry source="message, trace, ffdc"/>
 ----
 
-* The `mpTelemetry` configuration element is optional. If you do not specify ity or the `source` attribute, the default configuration source is `message`.
+* The `mpTelemetry` configuration element is optional. If you do not specify it or the `source` attribute, the default configuration source is `message`.
 
 * If the source attribute is empty (`source=“”`), no sources are collected, and nothing is routed to the configured OpenTelemetry logs exporter.
 
 * The attributes and values are case insensitive.
+
+[#dev]
+=== Customize your application telemetry with the OpenTelemetry API
+
+Although OpenTelemetry automatically collects a default set of logs, metrics, and traces, if you need to xref:ROOT:telemetry-trace.adoc[manually instrument your code to collect traces] or xref:ROOT:custom-mptelemetry-metrics.adoc[define custom metrics], you must make the OpenTelemetry API visible in your development environment.
+
+xref:ROOT:class-loader-library-config.adoc#3rd-party[Enable third-party APIs] for your application by adding the following code in your `server.xml` file:
+
+[source,xml]
+----
+<webApplication id="app-name" location="app-name.war">
+    <classloader apiTypeVisibility="+third-party"/>
+</webApplication>
+----
diff --git a/modules/reference/pages/javadoc/microprofile-7.0-javadoc.adoc b/modules/reference/pages/javadoc/microprofile-7.0-javadoc.adoc
new file mode 100644
index 0000000000..11877b75f6
--- /dev/null
+++ b/modules/reference/pages/javadoc/microprofile-7.0-javadoc.adoc
@@ -0,0 +1,15 @@
+// Copyright (c) 2023 IBM Corporation and others.
+// Licensed under Creative Commons Attribution-NoDerivatives
+// 4.0 International (CC BY-ND 4.0)
+//   https://creativecommons.org/licenses/by-nd/4.0/
+//
+// Contributors:
+//     IBM Corporation
+//
+:page-layout: javadoc
+= MicroProfile 7.0
+
+++++
+<iframe id="javadoc_container" title="MicroProfile 7.0 application programming interface" style="width: 100%;" frameBorder="0" src="/docs/modules/reference/microprofile-7.0-javadoc/index.html?overview-summary.html">
+</iframe>
+++++
diff --git a/modules/reference/pages/microprofile-config-properties.adoc b/modules/reference/pages/microprofile-config-properties.adoc
index a8a14e77d9..e91abce80e 100644
--- a/modules/reference/pages/microprofile-config-properties.adoc
+++ b/modules/reference/pages/microprofile-config-properties.adoc
@@ -29,7 +29,7 @@ The following sections provide tables that list and describe MicroProfile Config
 - <<#openapi,MicroProfile OpenAPI>>
 - <<#react,MicroProfile Reactive Messaging>>
 - <<#rest,MicroProfile Rest Client>>
-- <<#telemetry, MicroProfile Telemetry>>
+- <<#telemetry, MicroProfile Telemetry: OpenTelemetry properties>>
 
 
 [#context]
@@ -612,15 +612,16 @@ This property or `*/mp-rest/url` is considered required. However, some implement
 |===
 
 [#telemetry]
-== MicroProfile Telemetry
+== MicroProfile Telemetry: OpenTelemetry properties
 
-The following MicroProfile Config properties can be specified when MicroProfile Telemetry is enabled. This table lists the most important properties. For the full list, see the https://download.eclipse.org/microprofile/microprofile-telemetry-1.0/tracing/microprofile-telemetry-tracing-spec-1.0.html#_configuration[MicroProfile Telemetry specification].
+The following OpenTelemetry properties can be specified when MicroProfile Telemetry is enabled. This table lists the most important properties. For the full list, see the link:https://opentelemetry.io/docs/languages/java/configuration/#environment-variables-and-system-properties[OpenTelemtry Java configuration properties].
+
+You can enable OpenTelemetry at the runtime level to gather telemetry data from both the runtime and application. When you choose this option, you specify OpenTelemetry properties in runtime-level configuration sources instead of in application-level `microprofile-config.properties` files. In most cases, runtime-level configuration is preferred because it includes both runtime-level telemetry and application-specific telemetry. Alternatively, if your runtime hosts more tha one application, you can enable OpenTelemetry and and configure OpenTelemetry properties at the application level, for example, in microprofile-config.properties` files for each application. However, this option does not enable runtime telemetry. For more information, see xref:ROOT:microprofile-telemetry.adoc[OpenTelemetry].
 
-The runtime reads properties in the following table at either application startup or runtime startup, depending on when the OpenTelemetry instance initializes. In cases where each application is configured to use a separate OpenTelemetry instance, the runtime reads the properties at application startup. In cases where all applications on the runtime share a single OpenTelemetry instance, the runtime reads the properties at runtime startup.
 
-For more information about collecting Open Liberty logs, metrics, and traces, see xref:ROOT:microprofile-telemetry.adoc[Enable observability with MicroProfile Telemetry].
+The runtime reads properties in the following table at either application startup or runtime startup, depending on when the OpenTelemetry instance initializes. In cases where each application is configured to use a separate OpenTelemetry instance, the runtime reads the properties at application startup. In cases where all applications on the runtime share a single OpenTelemetry instance, the runtime reads the properties at runtime startup.
 
-.MicroProfile Config properties for MicroProfile Telemetry
+.OpenTelemetry properties enabled by MicroProfile Telemetry
 [options="header"]
 |===
 |Name |Description |When the runtime reads the property |Example
@@ -648,22 +649,42 @@ For more information about collecting Open Liberty logs, metrics, and traces, se
 |`otel.exporter.jaeger.endpoint`
 |Sets the endpoint for the Jaeger exporter. The default is \http://localhost:14250.
 |Application startup or runtime startup
-|`otel.exporter.jaeger.endpoint=http://localhost:14250`
+|`otel.exporter.jaeger.endpoint=http://localhost:14251`
 
 |`otel.exporter.jaeger.timeout`
 |Sets the maximum time, in milliseconds, that the Jaeger exporter waits for each batch export. The default is `10000`.
 |Application startup or runtime startup
-|`otel.exporter.jaeger.timeout=10000`
+|`otel.exporter.jaeger.timeout=20000`
 
 |`otel.exporter.otlp.endpoint`
 |Sets the endpoint for the OpenTelemetry Protocol (otlp) exporter. The default is \http://localhost:4317
 |Application startup or runtime startup
-|`otel.exporter.otlp.endpoint=http://localhost:4317`
+|`otel.exporter.otlp.endpoint=http://localhost:4319`
 
 |`otel.exporter.zipkin.endpoint`
 |Sets the endpoint for the Zipkin exporter. The default is \http://localhost:9411/api/v2/spans.
 |Application startup or runtime startup
-|`otel.exporter.zipkin.endpoint=http://localhost:9411/api/v2/spans`
+|`otel.exporter.zipkin.endpoint=http://localhost:9413/api/v2/spans`
+
+|`otel.logs.exporter`
+|You can use this property to change where the logs that  OpenTelemetry collects are exported.
+|Application startup or runtime startup
+|`otel.traces.exporter=console`
+
+|`otel.metric.export.interval`
+|By default, metric data is exported at an interval of 60000 milliseconds (one minute). To modify the export interval, specify the new value in milliseconds. For more information, see link:https://opentelemetry.io/docs/specs/otel/metrics/sdk/#periodic-exporting-metricreader[Periodic exporting MetricReader] in the OpenTelemetry documentation.
+|Application startup or runtime startup
+|`otel.metric.export.interval=120000`
+
+|`otel.metric.export.timeout`
+|By default, the maximum allowed time to export data is 30000 milliseconds (30 seconds). To modify the timeout value, specify a new value in milliseconds
+|Application startup or runtime startup
+|`otel.metric.export.timeout=60000`
+
+|`otel.metrics.exporter`
+|You can use this property to change where the metrics that OpenTelemetry collects are exported.
+|Application startup or runtime startup
+|`otel.metrics.exporter=prometheus`
 
 |`otel.sdk.disabled`
 |Enables logs, metrics, and traces to be sent to OpenTelemetry. The default is `true`.
@@ -671,18 +692,13 @@ For more information about collecting Open Liberty logs, metrics, and traces, se
 |`otel.sdk.disabled=false`
 
 |`otel.service.name`
-|Sets of the name of the service that MicroProfile Telemetry is tracing.
+|Sets of the name of the service that  OpenTelemetry is tracing.
 |Application startup or runtime startup
 |`otel.service.name=system`
 
-|`otel.logs.exporter`
-|You can use this property to change where the logs that MicroProfile Telemetry collects are exported. For more information, see xref:ROOT:microprofile-telemetry.adoc#logs[Configuring Open Liberty to use MicroProfile Telemetry to collect logs]
-|Application startup or runtime startup
-|`otel.traces.exporter=console`
-
 |`otel.traces.exporter`
 |Sets the exporter that is used to collect traces. Possible values are `otlp`, `zipkin`, `jaeger`, or `logging`. The default value is `otlp`. For the Jaeger trace service versions 1.35 and later, the `otlp` exporter value is recommended, rather than `jaeger`.
 |Application startup or runtime startup
-|`otel.traces.exporter=otlp`
+|`otel.traces.exporter=zipkin`
 
 |===