This is an automated email from the ASF dual-hosted git repository.
davsclaus pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/camel.git
The following commit(s) were added to refs/heads/main by this push:
new a8003bb094f7 Markdown format in source blocks (#19751)
a8003bb094f7 is described below
commit a8003bb094f7872c29f809ffe6419d194aba1393
Author: Andreas Jonsson <[email protected]>
AuthorDate: Wed Oct 29 14:38:05 2025 +0100
Markdown format in source blocks (#19751)
* Headings out of sync
* Headings out of sync
* Headings out of sync
* Headings out of sync
* Markdown source replaced with asciidoc
* Markdown source replaced with asciidoc
---
.../ROOT/pages/camel-4x-upgrade-guide-4_11.adoc | 7 ++++---
.../ROOT/pages/camel-4x-upgrade-guide-4_8.adoc | 6 ++++--
.../ROOT/pages/camel-report-maven-plugin.adoc | 5 +++--
.../user-manual/modules/ROOT/pages/health-check.adoc | 10 ++++++----
docs/user-manual/modules/ROOT/pages/jmx.adoc | 20 +++++++++++++-------
docs/user-manual/modules/ROOT/pages/mdc.adoc | 5 +++--
docs/user-manual/modules/ROOT/pages/route-group.adoc | 16 ++++++++++------
docs/user-manual/modules/ROOT/pages/test-infra.adoc | 10 ++++++----
8 files changed, 49 insertions(+), 30 deletions(-)
diff --git
a/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_11.adoc
b/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_11.adoc
index 773b3f930534..e6460ddbc7b7 100644
--- a/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_11.adoc
+++ b/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_11.adoc
@@ -126,13 +126,14 @@ The
`org.apache.camel.component.undertow.UndertowHeaderFilterStrategy` class has
=== camel-metrics
-A new gauge metric, `app.info` is available by default. This is providing a
few information related to the runtime provider such as:
+A new gauge metric, `app.info` is available by default. This is providing
information related to the runtime provider such as:
-```
+[source, bash]
+----
# HELP app_info
# TYPE app_info gauge
app_info{camel_context="camel-1",camel_runtime_provider="Spring-Boot",camel_runtime_version="3.4.3",camel_version="4.10.2"}
1
-```
+----
This information is evaluated at runtime startup and available through the
usual metrics endpoint. To disable this metric you need to use the
`camel.metrics.skipCamelInfo=true` property.
diff --git
a/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_8.adoc
b/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_8.adoc
index 583e7c6be988..20fd6f356d11 100644
--- a/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_8.adoc
+++ b/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_8.adoc
@@ -50,7 +50,9 @@ on Spring Boot.
In order to fix the problems reported we had to align the Opentelemetry
dependencies to a version which is different from the one used in Spring Boot
3.3.x BOM.
If you're using such BOM for your **Camel Spring Boot runtime** application,
you will need to make sure to force the usage of the Opentelemetry dependencies
below:
-```
+
+[source, xml]
+----
<dependency>
<groupId>io.opentelemetry</groupId>
<artifactId>opentelemetry-sdk</artifactId>
@@ -101,7 +103,7 @@ If you're using such BOM for your **Camel Spring Boot
runtime** application, you
<artifactId>opentelemetry-api-incubator</artifactId>
<version>1.43.0-alpha</version>
</dependency>
-```
+----
== Upgrading Camel 4.7 to 4.8
diff --git a/docs/user-manual/modules/ROOT/pages/camel-report-maven-plugin.adoc
b/docs/user-manual/modules/ROOT/pages/camel-report-maven-plugin.adoc
index f3a513e7e1cb..35b595ec4e7c 100644
--- a/docs/user-manual/modules/ROOT/pages/camel-report-maven-plugin.adoc
+++ b/docs/user-manual/modules/ROOT/pages/camel-report-maven-plugin.adoc
@@ -183,7 +183,8 @@ In particular, in order to use the validate plugin with
transitive dependencies,
* The route `from("direct:out")` is declared into a dependency of your
project, for example `my.company:routes-dependency:1.0`
* If `routes-dependency` sources are released into a maven repository, the
following plugin configuration can be used:
-```xml
+[source, xml]
+----
<plugin>
<groupId>org.apache.camel</groupId>
<artifactId>camel-report-maven-plugin</artifactId>
@@ -204,7 +205,7 @@ In particular, in order to use the validate plugin with
transitive dependencies,
</execution>
</executions>
</plugin>
-```
+----
== camel-report:route-coverage
diff --git a/docs/user-manual/modules/ROOT/pages/health-check.adoc
b/docs/user-manual/modules/ROOT/pages/health-check.adoc
index 49821d7aa0cf..751e2dcdccce 100644
--- a/docs/user-manual/modules/ROOT/pages/health-check.adoc
+++ b/docs/user-manual/modules/ROOT/pages/health-check.adoc
@@ -102,7 +102,8 @@ if (consumersHealthCheckRepository != null) {
Once you have the health check exposed as a service and the application is up
and running, you can check it by accessing the related endpoint:
-```
+[source, console]
+----
$ curl http://localhost:9876/observe/health
{
"status": "UP"
@@ -119,13 +120,14 @@ $ curl http://localhost:9876/observe/health
"status": "UP" }
]
}
-```
+----
NOTE: the port and the path can change depending on the runtime used and the
configuration.
When you're running on certain runtimes you will get more information by
default. This is also possible in the `camel-main` runtime provider. However,
you'll need to specify that as a request parameter:
-```
+[source, console]
+----
$ curl http://localhost:9876/observe/health?data=true
{
"status": "UP"
@@ -151,7 +153,7 @@ $ curl http://localhost:9876/observe/health?data=true
}
},
...
-```
+----
=== Configuring initial state
diff --git a/docs/user-manual/modules/ROOT/pages/jmx.adoc
b/docs/user-manual/modules/ROOT/pages/jmx.adoc
index 28c4f007ee5b..4ea03a0a7153 100644
--- a/docs/user-manual/modules/ROOT/pages/jmx.adoc
+++ b/docs/user-manual/modules/ROOT/pages/jmx.adoc
@@ -343,19 +343,25 @@ NOTE: make sure to properly secure the access to JMX
services for production wor
== How to use a Java Agent
Exposing the JMX metrics with its native protocol may not always be possible
(ie, for firewall limitations, security, etc). In this case you may recur to
the availability of JSR 160 compatible Java Agents (for instance,
https://jolokia.org/reference/html/manual/agents.html#agents-jvm[Jolokia]),
which goal is to adapt the JMX interface with HTTP based protocol. With this
approach you can run you application attaching a Java Agent whose goal will be
to take care of exposing JMX via HTTP. A [...]
-```
+
+[source, java]
+----
java -javaagent:jsr160-javaagent.jar -jar my-camel-app.jar
-```
+----
+
will expose certain endpoints (depending on the implementation) which would
let you interact with JMX.
Depending on the implementation you will need to provide to a different set of
agent configuration. For example, if you're running Jolokia agent, then, you
will need to run this configuration to expose a plain HTTP unsecure service:
-```
+
+[source, console]
+----
java
-javaagent:jolokia-agent-jvm-2.1.1-javaagent.jar=protocol=http,useSslClientAuthentication=false,discoveryEnabled=false,host=*,extendedClientCheck=false
-jar my-camel-app.jar
-```
-From that moment onward you will be able to access the service via:
+----
-```
+From that moment onward you will be able to access the service via:
+[source, console]
+----
$ curl http://localhost:8778/jolokia/list/org.apache.camel | jq | more
{
"request": {
@@ -381,7 +387,7 @@ $ curl http://localhost:8778/jolokia/list/org.apache.camel
| jq | more
"desc": "ComponentName"
},
...
-```
+----
Each agent implementation may provide a different way to get and execute
actions on the various endpoint.
diff --git a/docs/user-manual/modules/ROOT/pages/mdc.adoc
b/docs/user-manual/modules/ROOT/pages/mdc.adoc
index 86c0e840056e..eb6ebdd1b941 100644
--- a/docs/user-manual/modules/ROOT/pages/mdc.adoc
+++ b/docs/user-manual/modules/ROOT/pages/mdc.adoc
@@ -27,9 +27,10 @@ You can use the above variables for MDC depending on the
logging framework you'r
If you're using Java DSL you can include any customized information by adding
that using low level MDC API:
-```java
+[source, java]
+----
org.slf4j.MDC.put("myKey", "myValue");
-```
+----
Each MDC should be now able to include that information.
diff --git a/docs/user-manual/modules/ROOT/pages/route-group.adoc
b/docs/user-manual/modules/ROOT/pages/route-group.adoc
index d92a71bc7bac..8e3f09693a3c 100644
--- a/docs/user-manual/modules/ROOT/pages/route-group.adoc
+++ b/docs/user-manual/modules/ROOT/pages/route-group.adoc
@@ -88,14 +88,16 @@ The camel API allows to retrieve all routes of a group and
then perform various
Here is an example to suspend all routes of a group:
-```java
+[source, java]
+----
+java
List<Route> routes = context.getRoutesByGroup("order");
for (Route route : routes) {
System.out.println("Suspend routeId=" + route.getId() + " for group=" +
route.getGroup());
route.getRouteController().suspendRoute(route.getId());
}
-```
+----
== Monitoring
@@ -104,18 +106,20 @@ Camel has optional support for xref:jmx.adoc[JMX
management]. This includes mana
To get all failed changes for a group:
-```java
+[source, java]
+----
ManagedCamelContext managedContext =
context.getCamelContextExtension().getContextPlugin(ManagedCamelContext.class);
ManagedRouteGroupMBean managedRouteGroup =
managedContext.getManagedRouteGroup("order");
if(managedRouteGroup!=null){
System.out.println("Group order has " +
managedRouteGroup.getExchangesFailed() + " failed exchanges");
}
-```
+----
To get all failed changes for every route in a group:
-```java
+[source, java]
+----
ManagedCamelContext managedContext =
context.getCamelContextExtension().getContextPlugin(ManagedCamelContext.class);
List<ManagedRouteMBean> routes =
managedContext.getManagedRoutesByGroup(flowId);
@@ -123,4 +127,4 @@ List<ManagedRouteMBean> routes =
managedContext.getManagedRoutesByGroup(flowId);
for (ManagedRouteMBean route : routes) {
System.out.println("RouteId=" + route.getRouteId() + " has " +
route.getExchangesFailed() + " failed exchanges");
}
-```
+----
diff --git a/docs/user-manual/modules/ROOT/pages/test-infra.adoc
b/docs/user-manual/modules/ROOT/pages/test-infra.adoc
index 237846a8dd91..9bea32f6b7ce 100644
--- a/docs/user-manual/modules/ROOT/pages/test-infra.adoc
+++ b/docs/user-manual/modules/ROOT/pages/test-infra.adoc
@@ -73,13 +73,14 @@ interface.
Ideally, there should be two concrete implementations of the services: one of
the remote service (if applicable) and
another for the container service:
-```
+[source, bash]
+----
MyService
/ \
/ \
/ \
MyRemoteService MyContainerService
-```
+----
In most cases, a specialized service factory class is responsible for creating
the service according to runtime
@@ -254,9 +255,10 @@ Assuming Podman is properly installed and configured to
behave like docker (i.e.
On most systems that should be similar to the following command:
-```
+[source, console]
+----
export DOCKER_HOST=unix:///run/user/$UID/podman/podman.sock
-```
+----
==== OS X and Windows
