You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@camel.apache.org by da...@apache.org on 2026/09/14 04:34:10 UTC
(camel) branch main updated: chore(docs): escape wildcards in monospace so pages render valid HTML (#26380)
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 fcb828d23fdd chore(docs): escape wildcards in monospace so pages render valid HTML (#26380)
fcb828d23fdd is described below
commit fcb828d23fdd6f90dbee324b5eb0f1e9004d8b97
Author: Adriano Machado <60...@users.noreply.github.com>
AuthorDate: Mon Sep 14 00:34:03 2026 -0400
chore(docs): escape wildcards in monospace so pages render valid HTML (#26380)
A * or # inside a single-backtick span is still parsed as a formatting
mark, so spans such as `mail.smtp.*` or `core/camel-*` pair up with a
later * and produce mis-nested HTML like <code>…<strong></code>…</strong>.
Browsers tolerate it, but the website's HTML-to-Markdown step then loses
article.doc and skips the page, so its .md mirror (linked from llms.txt)
returns 404 (apache/camel-website#1746).
Use literal monospace (`+…+`) for those spans, double backticks where a
span is followed by a quote, and `++/model ++` for a span with a
trailing space. Also fixes spans that stayed valid HTML but still
rendered bold text instead of the * characters. Catalog doc copies are
synced.
_Claude Code on behalf of Adriano Machado (@ammachado)_
_This was generated by an AI agent and may contain inaccuracies.
Please verify before relying on it._
---
.../camel/catalog/docs/ai-tool-component.adoc | 6 +--
.../apache/camel/catalog/docs/mail-component.adoc | 4 +-
.../org/apache/camel/catalog/docs/mcp-server.adoc | 8 ++--
.../org/apache/camel/catalog/docs/mdc.adoc | 4 +-
.../apache/camel/catalog/docs/opa-component.adoc | 2 +-
.../org/apache/camel/catalog/docs/yaml-dsl.adoc | 2 +-
.../src/main/docs/ai-tool-component.adoc | 6 +--
.../camel-mcp-server/src/main/docs/mcp-server.adoc | 8 ++--
.../camel-mail/src/main/docs/mail-component.adoc | 4 +-
components/camel-mdc/src/main/docs/mdc.adoc | 4 +-
.../camel-opa/src/main/docs/opa-component.adoc | 2 +-
.../ROOT/pages/camel-4x-upgrade-guide-4_14.adoc | 10 ++---
.../ROOT/pages/camel-4x-upgrade-guide-4_18.adoc | 16 +++----
.../ROOT/pages/camel-4x-upgrade-guide-4_19.adoc | 6 +--
.../ROOT/pages/camel-4x-upgrade-guide-4_21.adoc | 36 ++++++++--------
.../ROOT/pages/camel-4x-upgrade-guide-4_22.adoc | 4 +-
.../ROOT/pages/camel-4x-upgrade-guide-4_23.adoc | 16 +++----
.../modules/ROOT/pages/camel-jbang-mcp.adoc | 2 +-
.../modules/ROOT/pages/camel-jbang-tui.adoc | 8 ++--
.../modules/ROOT/pages/security-model.adoc | 50 +++++++++++-----------
.../camel-yaml-dsl/src/main/docs/yaml-dsl.adoc | 2 +-
21 files changed, 100 insertions(+), 100 deletions(-)
diff --git a/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/ai-tool-component.adoc b/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/ai-tool-component.adoc
index 911e5feb21c9..13e9da463c4e 100644
--- a/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/ai-tool-component.adoc
+++ b/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/ai-tool-component.adoc
@@ -147,7 +147,7 @@ YAML::
=== Complex Parameters with argSchema
-Use `argSchema` when the flat `parameter.*` syntax is not expressive enough for nested objects, arrays, or other advanced JSON Schema constructs. `argSchema` is mutually exclusive with `parameter.*`.
+Use `argSchema` when the flat `+parameter.*+` syntax is not expressive enough for nested objects, arrays, or other advanced JSON Schema constructs. `argSchema` is mutually exclusive with `+parameter.*+`.
[tabs]
====
@@ -199,7 +199,7 @@ The root schema must be a JSON Schema object with a top-level `properties` map.
=== Structured Tool Output (outputSchema)
-MCP tools can declare an `outputSchema` and return `structuredContent` (typed JSON) so clients parse tool results reliably instead of re-interpreting free text. Use `outputParameter.*` for flat field definitions or `outputSchema` for raw JSON Schema (mirroring the input-side `parameter.*` / `argSchema` pattern). The two options are mutually exclusive.
+MCP tools can declare an `outputSchema` and return `structuredContent` (typed JSON) so clients parse tool results reliably instead of re-interpreting free text. Use `+outputParameter.*+` for flat field definitions or `outputSchema` for raw JSON Schema (mirroring the input-side `+parameter.*+` / `argSchema` pattern). The two options are mutually exclusive.
When an output schema is declared, the route body must be JSON (a JSON string, `Map`, or `List`). Camel parses it into structured content and forwards it through the MCP bridge as `CallToolResult.structuredContent`. The text representation remains available for LLM adapters (LangChain4j, Spring AI) that consume string tool results.
@@ -232,7 +232,7 @@ YAML::
----
====
-Flat `outputParameter.*` options use the same sub-option syntax as input `parameter.*`:
+Flat `+outputParameter.*+` options use the same sub-option syntax as input `+parameter.*+`:
* `outputParameter.NAME=TYPE` — field type (`string`, `integer`, `number`, `boolean`)
* `outputParameter.NAME.description=TEXT` — field description in the generated JSON Schema
diff --git a/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/mail-component.adoc b/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/mail-component.adoc
index a614e7fd5e8a..71ff5a3698f9 100644
--- a/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/mail-component.adoc
+++ b/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/mail-component.adoc
@@ -899,11 +899,11 @@ For example, to provide a dynamic uuid in `mail.smtp.from` (SMTP MAIL command):
NOTE: This is only supported when *not* using a custom `JavaMailSender`.
WARNING: This feature is *disabled by default* and must be explicitly enabled with
-`useJavaMailSessionPropertiesFromHeaders=true`. The `mail.smtp.*` / `mail.smtps.*` keys are a
+`useJavaMailSessionPropertiesFromHeaders=true`. The `+mail.smtp.*+` / `+mail.smtps.*+` keys are a
Camel-internal namespace that is not filtered by any `HeaderFilterStrategy`, so if these headers can
originate from data crossing a trust boundary (for example HTTP query parameters, or JMS/Kafka
messages from untrusted producers) an attacker could weaken transport security (such as
`mail.smtp.ssl.trust` or `mail.smtp.starttls.enable`) or redirect the SMTP connection. Only enable
the option when these headers are set exclusively by trusted route logic, and strip the namespace
-with `removeHeaders("mail.smtp.*", "mail.smtps.*")` before the producer when bridging an untrusted
+with `+removeHeaders("mail.smtp.*", "mail.smtps.*")+` before the producer when bridging an untrusted
source. See the xref:manual::security-model.adoc[Camel Security Model] for the general pattern.
diff --git a/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/mcp-server.adoc b/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/mcp-server.adoc
index 78ed283ed140..244c4f304a53 100644
--- a/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/mcp-server.adoc
+++ b/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/mcp-server.adoc
@@ -51,9 +51,9 @@ Engine resolution mirrors the platform-http engine: a bean of type
`McpServerEngine` in the Camel registry wins; otherwise the engine is
discovered on the classpath. Other runtimes plug native engines through the
same SPI: on Quarkus the `camel-quarkus-mcp-server` extension serves through
-the Quarkiverse `quarkus-mcp-server` (configured via `quarkus.mcp.server.*`),
+the Quarkiverse `quarkus-mcp-server` (configured via `+quarkus.mcp.server.*+`),
and on Spring Boot the starter serves through the Spring AI MCP server
-(configured via `spring.ai.mcp.server.*`). Bridge behavior — tag selection,
+(configured via `+spring.ai.mcp.server.*+`). Bridge behavior — tag selection,
timeout, sanitization — is identical on every runtime and verified by a shared
conformance test kit.
@@ -163,8 +163,8 @@ camel.server.mcp-instructions = Use these tools to operate the integration.
camel.server.mcp-server-icons = [{"src":"https://example.com/icon.png","mimeType":"image/png","sizes":["48x48"],"theme":"light"}]
----
-Tag patterns support wildcards: use `*` to expose all tagged tools, or a
-prefix pattern like `crm*` to expose all tags starting with `crm`:
+Tag patterns support wildcards: use `+*+` to expose all tagged tools, or a
+prefix pattern like `+crm*+` to expose all tags starting with `crm`:
The MCP endpoint is then served at `http://<host>:<port>/mcp` on the Camel
main HTTP server. Any MCP client can connect over streamable HTTP, for
diff --git a/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/mdc.adoc b/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/mdc.adoc
index 708d9ca4a8d0..fcaae53169ac 100644
--- a/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/mdc.adoc
+++ b/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/mdc.adoc
@@ -70,6 +70,6 @@ The configuration properties for the MDC component are:
|=======================================================================
|Option |Default |Description
|`camel.mdc.enabled`| false | Enable the MDC logging.
-|`camel.mdc.customExchangeHeaders` | | Provide the exchange headers you would like to trace in MDC. Use `*` value as a wildcard to include more exchange headers at once, for example `CAMEL_HTTP_*` or only the `*` to include all available exchange headers.
-|`camel.mdc.customExchangeProperties` | | Provide the exchange properties you would like to trace in MDC. Use `*` value as a wildcard to include more exchange properties at once, for example `property_*` or only the `*` to include all available exchange properties.
+|`camel.mdc.customExchangeHeaders` | | Provide the exchange headers you would like to trace in MDC. Use `+*+` value as a wildcard to include more exchange headers at once, for example `+CAMEL_HTTP_*+` or only the `+*+` to include all available exchange headers.
+|`camel.mdc.customExchangeProperties` | | Provide the exchange properties you would like to trace in MDC. Use `+*+` value as a wildcard to include more exchange properties at once, for example `+property_*+` or only the `+*+` to include all available exchange properties.
|=======================================================================
diff --git a/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/opa-component.adoc b/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/opa-component.adoc
index e57b5c85ee49..b20e097915a9 100644
--- a/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/opa-component.adoc
+++ b/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/opa-component.adoc
@@ -180,7 +180,7 @@ allow if {
}
------------------------------------------------------------
-`includeProperties` takes a comma-separated list, or `*` for all of them, and matches names case-insensitively.
+`includeProperties` takes a comma-separated list, or `+*+` for all of them, and matches names case-insensitively.
Unlike `includeHeaders` it is *empty by default*: exchange properties are mostly used to carry state between
processors, so sending them all would be noise the policy has to wade through. Only custom properties are sent —
Camel's own internal exchange properties are never included.
diff --git a/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/yaml-dsl.adoc b/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/yaml-dsl.adoc
index 6773f8a975c4..e8d9b667269a 100644
--- a/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/yaml-dsl.adoc
+++ b/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/yaml-dsl.adoc
@@ -837,7 +837,7 @@ a simpler, more predictable schema structure. The classic schema remains the def
=== Using the schemas with IDEs
The classic schema is registered in the https://www.schemastore.org/[JSON Schema Store] and is automatically
-used by IDEs like VS Code and IntelliJ for files matching `*.camel.yaml` and `*.camelk.yaml`.
+used by IDEs like VS Code and IntelliJ for files matching `+*.camel.yaml+` and `+*.camelk.yaml+`.
To use the canonical schema instead, configure your IDE to point to the canonical schema URL:
diff --git a/components/camel-ai/camel-ai-tool/src/main/docs/ai-tool-component.adoc b/components/camel-ai/camel-ai-tool/src/main/docs/ai-tool-component.adoc
index 911e5feb21c9..13e9da463c4e 100644
--- a/components/camel-ai/camel-ai-tool/src/main/docs/ai-tool-component.adoc
+++ b/components/camel-ai/camel-ai-tool/src/main/docs/ai-tool-component.adoc
@@ -147,7 +147,7 @@ YAML::
=== Complex Parameters with argSchema
-Use `argSchema` when the flat `parameter.*` syntax is not expressive enough for nested objects, arrays, or other advanced JSON Schema constructs. `argSchema` is mutually exclusive with `parameter.*`.
+Use `argSchema` when the flat `+parameter.*+` syntax is not expressive enough for nested objects, arrays, or other advanced JSON Schema constructs. `argSchema` is mutually exclusive with `+parameter.*+`.
[tabs]
====
@@ -199,7 +199,7 @@ The root schema must be a JSON Schema object with a top-level `properties` map.
=== Structured Tool Output (outputSchema)
-MCP tools can declare an `outputSchema` and return `structuredContent` (typed JSON) so clients parse tool results reliably instead of re-interpreting free text. Use `outputParameter.*` for flat field definitions or `outputSchema` for raw JSON Schema (mirroring the input-side `parameter.*` / `argSchema` pattern). The two options are mutually exclusive.
+MCP tools can declare an `outputSchema` and return `structuredContent` (typed JSON) so clients parse tool results reliably instead of re-interpreting free text. Use `+outputParameter.*+` for flat field definitions or `outputSchema` for raw JSON Schema (mirroring the input-side `+parameter.*+` / `argSchema` pattern). The two options are mutually exclusive.
When an output schema is declared, the route body must be JSON (a JSON string, `Map`, or `List`). Camel parses it into structured content and forwards it through the MCP bridge as `CallToolResult.structuredContent`. The text representation remains available for LLM adapters (LangChain4j, Spring AI) that consume string tool results.
@@ -232,7 +232,7 @@ YAML::
----
====
-Flat `outputParameter.*` options use the same sub-option syntax as input `parameter.*`:
+Flat `+outputParameter.*+` options use the same sub-option syntax as input `+parameter.*+`:
* `outputParameter.NAME=TYPE` — field type (`string`, `integer`, `number`, `boolean`)
* `outputParameter.NAME.description=TEXT` — field description in the generated JSON Schema
diff --git a/components/camel-ai/camel-mcp-server/src/main/docs/mcp-server.adoc b/components/camel-ai/camel-mcp-server/src/main/docs/mcp-server.adoc
index 78ed283ed140..244c4f304a53 100644
--- a/components/camel-ai/camel-mcp-server/src/main/docs/mcp-server.adoc
+++ b/components/camel-ai/camel-mcp-server/src/main/docs/mcp-server.adoc
@@ -51,9 +51,9 @@ Engine resolution mirrors the platform-http engine: a bean of type
`McpServerEngine` in the Camel registry wins; otherwise the engine is
discovered on the classpath. Other runtimes plug native engines through the
same SPI: on Quarkus the `camel-quarkus-mcp-server` extension serves through
-the Quarkiverse `quarkus-mcp-server` (configured via `quarkus.mcp.server.*`),
+the Quarkiverse `quarkus-mcp-server` (configured via `+quarkus.mcp.server.*+`),
and on Spring Boot the starter serves through the Spring AI MCP server
-(configured via `spring.ai.mcp.server.*`). Bridge behavior — tag selection,
+(configured via `+spring.ai.mcp.server.*+`). Bridge behavior — tag selection,
timeout, sanitization — is identical on every runtime and verified by a shared
conformance test kit.
@@ -163,8 +163,8 @@ camel.server.mcp-instructions = Use these tools to operate the integration.
camel.server.mcp-server-icons = [{"src":"https://example.com/icon.png","mimeType":"image/png","sizes":["48x48"],"theme":"light"}]
----
-Tag patterns support wildcards: use `*` to expose all tagged tools, or a
-prefix pattern like `crm*` to expose all tags starting with `crm`:
+Tag patterns support wildcards: use `+*+` to expose all tagged tools, or a
+prefix pattern like `+crm*+` to expose all tags starting with `crm`:
The MCP endpoint is then served at `http://<host>:<port>/mcp` on the Camel
main HTTP server. Any MCP client can connect over streamable HTTP, for
diff --git a/components/camel-mail/src/main/docs/mail-component.adoc b/components/camel-mail/src/main/docs/mail-component.adoc
index a614e7fd5e8a..71ff5a3698f9 100644
--- a/components/camel-mail/src/main/docs/mail-component.adoc
+++ b/components/camel-mail/src/main/docs/mail-component.adoc
@@ -899,11 +899,11 @@ For example, to provide a dynamic uuid in `mail.smtp.from` (SMTP MAIL command):
NOTE: This is only supported when *not* using a custom `JavaMailSender`.
WARNING: This feature is *disabled by default* and must be explicitly enabled with
-`useJavaMailSessionPropertiesFromHeaders=true`. The `mail.smtp.*` / `mail.smtps.*` keys are a
+`useJavaMailSessionPropertiesFromHeaders=true`. The `+mail.smtp.*+` / `+mail.smtps.*+` keys are a
Camel-internal namespace that is not filtered by any `HeaderFilterStrategy`, so if these headers can
originate from data crossing a trust boundary (for example HTTP query parameters, or JMS/Kafka
messages from untrusted producers) an attacker could weaken transport security (such as
`mail.smtp.ssl.trust` or `mail.smtp.starttls.enable`) or redirect the SMTP connection. Only enable
the option when these headers are set exclusively by trusted route logic, and strip the namespace
-with `removeHeaders("mail.smtp.*", "mail.smtps.*")` before the producer when bridging an untrusted
+with `+removeHeaders("mail.smtp.*", "mail.smtps.*")+` before the producer when bridging an untrusted
source. See the xref:manual::security-model.adoc[Camel Security Model] for the general pattern.
diff --git a/components/camel-mdc/src/main/docs/mdc.adoc b/components/camel-mdc/src/main/docs/mdc.adoc
index 708d9ca4a8d0..fcaae53169ac 100644
--- a/components/camel-mdc/src/main/docs/mdc.adoc
+++ b/components/camel-mdc/src/main/docs/mdc.adoc
@@ -70,6 +70,6 @@ The configuration properties for the MDC component are:
|=======================================================================
|Option |Default |Description
|`camel.mdc.enabled`| false | Enable the MDC logging.
-|`camel.mdc.customExchangeHeaders` | | Provide the exchange headers you would like to trace in MDC. Use `*` value as a wildcard to include more exchange headers at once, for example `CAMEL_HTTP_*` or only the `*` to include all available exchange headers.
-|`camel.mdc.customExchangeProperties` | | Provide the exchange properties you would like to trace in MDC. Use `*` value as a wildcard to include more exchange properties at once, for example `property_*` or only the `*` to include all available exchange properties.
+|`camel.mdc.customExchangeHeaders` | | Provide the exchange headers you would like to trace in MDC. Use `+*+` value as a wildcard to include more exchange headers at once, for example `+CAMEL_HTTP_*+` or only the `+*+` to include all available exchange headers.
+|`camel.mdc.customExchangeProperties` | | Provide the exchange properties you would like to trace in MDC. Use `+*+` value as a wildcard to include more exchange properties at once, for example `+property_*+` or only the `+*+` to include all available exchange properties.
|=======================================================================
diff --git a/components/camel-opa/src/main/docs/opa-component.adoc b/components/camel-opa/src/main/docs/opa-component.adoc
index e57b5c85ee49..b20e097915a9 100644
--- a/components/camel-opa/src/main/docs/opa-component.adoc
+++ b/components/camel-opa/src/main/docs/opa-component.adoc
@@ -180,7 +180,7 @@ allow if {
}
------------------------------------------------------------
-`includeProperties` takes a comma-separated list, or `*` for all of them, and matches names case-insensitively.
+`includeProperties` takes a comma-separated list, or `+*+` for all of them, and matches names case-insensitively.
Unlike `includeHeaders` it is *empty by default*: exchange properties are mostly used to carry state between
processors, so sending them all would be noise the policy has to wade through. Only custom properties are sent —
Camel's own internal exchange properties are never included.
diff --git a/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_14.adoc b/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_14.adoc
index 1c5d0639007a..2799ad236521 100644
--- a/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_14.adoc
+++ b/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_14.adoc
@@ -1047,12 +1047,12 @@ without changes. Routes that set the headers by their literal string value
Because the renamed prefixes now begin with `Camel`, they are stripped by the
standard transport `HeaderFilterStrategy` (`HttpHeaderFilterStrategy`, etc.)
-when crossing a transport boundary, by design — `Camel*` headers are
+when crossing a transport boundary, by design — `+Camel*+` headers are
framework-internal and are not propagated over the wire. Routes that bridge an
external transport (HTTP, JMS, ...) into a `solr:` producer and want to drive
Solr document fields or query parameters from a header supplied by the sender
must therefore carry the value in a non-`Camel`-prefixed application header and
-map it to the appropriate `CamelSolrField.*` / `CamelSolrParam.*` header in the
+map it to the appropriate `+CamelSolrField.*+` / `+CamelSolrParam.*+` header in the
route between the transport `from` and the `solr:` `to`.
=== camel-dapr - potential breaking change
@@ -1263,9 +1263,9 @@ effect from 4.14.9 onwards; see the
entry below.
====
-`UndertowHeaderFilterStrategy` now also filters the legacy `websocket.*`
-Exchange-header prefix (in addition to the `Camel*` / `camel*` /
-`org.apache.camel.*` prefixes it already filtered). This applies to both the
+`UndertowHeaderFilterStrategy` now also filters the legacy `+websocket.*+`
+Exchange-header prefix (in addition to the `+Camel*+` / `+camel*+` /
+`+org.apache.camel.*+` prefixes it already filtered). This applies to both the
in (wire -> exchange) and out (exchange -> wire) directions and follows the
dedicated-filter-strategy shape used by CAMEL-23532 for
`camel-vertx-websocket` / `camel-atmosphere-websocket` / `camel-iggy`.
diff --git a/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_18.adoc b/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_18.adoc
index 8787e26c2f1e..c4923b32658c 100644
--- a/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_18.adoc
+++ b/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_18.adoc
@@ -186,7 +186,7 @@ and any type a cluster peer sent was routed.
When no explicit pattern is configured, the JVM-wide `jdk.serialFilter` is honoured if set,
otherwise a conservative default allow-list is applied
-(`!java.net.**;java.**;javax.**;org.apache.camel.**;!*`), matching the default the other components
+(`+!java.net.**;java.**;javax.**;org.apache.camel.**;!*+`), matching the default the other components
that can receive Java-serialized payloads have applied since 4.18.3. Routes that exchange their own
classes over the cluster must widen it through the new `deserializationFilter` endpoint option, for
example:
@@ -633,7 +633,7 @@ messages from untrusted producers) could override transport-security settings su
`mail.smtp.ssl.trust` or `mail.smtp.starttls.enable`, or redirect the SMTP connection.
This behaviour is now disabled by default. Routes that legitimately rely on per-message
-`mail.smtp.*` / `mail.smtps.*` headers must opt back in on the endpoint:
+`+mail.smtp.*+` / `+mail.smtps.*+` headers must opt back in on the endpoint:
._Java-only: opting in to JavaMail session properties from headers_
[source,java]
@@ -642,7 +642,7 @@ This behaviour is now disabled by default. Routes that legitimately rely on per-
----
Even with the opt-in, route authors should still strip the namespace with
-`removeHeaders("mail.smtp.*", "mail.smtps.*")` between any untrusted ingress and the mail producer.
+`+removeHeaders("mail.smtp.*", "mail.smtps.*")+` between any untrusted ingress and the mail producer.
In addition, the inbound `MailHeaderFilterStrategy` now blocks the `mail.smtp.` / `mail.smtps.`
prefix as well, so an external mail message can no longer inject these into a downstream exchange.
@@ -1394,12 +1394,12 @@ without changes. Routes that set the headers by their literal string value
Because the renamed prefixes now begin with `Camel`, they are stripped by the
standard transport `HeaderFilterStrategy` (`HttpHeaderFilterStrategy`, etc.)
-when crossing a transport boundary, by design — `Camel*` headers are
+when crossing a transport boundary, by design — `+Camel*+` headers are
framework-internal and are not propagated over the wire. Routes that bridge an
external transport (HTTP, JMS, ...) into a `solr:` producer and want to drive
Solr document fields or query parameters from a header supplied by the sender
must therefore carry the value in a non-`Camel`-prefixed application header and
-map it to the appropriate `CamelSolrField.*` / `CamelSolrParam.*` header in the
+map it to the appropriate `+CamelSolrField.*+` / `+CamelSolrParam.*+` header in the
route between the transport `from` and the `solr:` `to`.
=== camel-dapr - potential breaking change
@@ -1802,9 +1802,9 @@ effect from 4.18.4 onwards; see the
entry below.
====
-`UndertowHeaderFilterStrategy` now also filters the legacy `websocket.*`
-Exchange-header prefix (in addition to the `Camel*` / `camel*` /
-`org.apache.camel.*` prefixes it already filtered). This applies to both the
+`UndertowHeaderFilterStrategy` now also filters the legacy `+websocket.*+`
+Exchange-header prefix (in addition to the `+Camel*+` / `+camel*+` /
+`+org.apache.camel.*+` prefixes it already filtered). This applies to both the
in (wire -> exchange) and out (exchange -> wire) directions and follows the
dedicated-filter-strategy shape used by CAMEL-23532 for
`camel-vertx-websocket` / `camel-atmosphere-websocket` / `camel-iggy`.
diff --git a/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_19.adoc b/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_19.adoc
index 5e4a331e4066..ffb0c2d2daa4 100644
--- a/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_19.adoc
+++ b/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_19.adoc
@@ -323,9 +323,9 @@ After:
</dependency>
----
-You will also need to change any imports of classes in `org.apache.camel.test.junit5.*` to `import org.apache.camel.test.junit6.*`.
+You will also need to change any imports of classes in `+org.apache.camel.test.junit5.*+` to `+import org.apache.camel.test.junit6.*+`.
-Similarly, for camel-test-main-junit5 you would need to change any imports of classes in `org.apache.camel.test.main.junit5.*` to `org.apache.camel.test.main.junit6.*`, and the dependency in your pom.xml would change from:
+Similarly, for camel-test-main-junit5 you would need to change any imports of classes in `+org.apache.camel.test.main.junit5.*+` to `+org.apache.camel.test.main.junit6.*+`, and the dependency in your pom.xml would change from:
Before:
[source,xml]
@@ -349,7 +349,7 @@ After:
</dependency>
----
-Finally, for camel-test-spring-junit5 any imports would change from `org.apache.camel.test.spring.junit5.*` to `import org.apache.camel.test.spring.junit6.*` and the dependency change would be :
+Finally, for camel-test-spring-junit5 any imports would change from `+org.apache.camel.test.spring.junit5.*+` to `+import org.apache.camel.test.spring.junit6.*+` and the dependency change would be :
Before:
[source,xml]
diff --git a/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_21.adoc b/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_21.adoc
index 94472b7edfa8..ed522d0008c1 100644
--- a/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_21.adoc
+++ b/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_21.adoc
@@ -408,9 +408,9 @@ Set `validateAuth=false` explicitly only when intentionally serving unauthentica
=== camel-kafka / Spring Boot
-When using `camel-kafka-starter` with Spring Boot, the standard `spring.kafka.*` properties are now automatically
+When using `camel-kafka-starter` with Spring Boot, the standard `+spring.kafka.*+` properties are now automatically
bridged to the Camel Kafka component configuration (CAMEL-22760). This means you no longer need to duplicate
-Kafka settings under both `spring.kafka.*` and `camel.component.kafka.*`.
+Kafka settings under both `+spring.kafka.*+` and `+camel.component.kafka.*+`.
The bridged properties include `bootstrap-servers`, `security.protocol`, SSL/TLS settings (keystore, truststore),
`consumer.group-id`, `client-id`, and SASL properties (`sasl.mechanism`, `sasl.jaas.config`, `sasl.kerberos.service.name`).
@@ -427,8 +427,8 @@ camel.component.kafka.bridge-spring-kafka-properties=false
=== Default deserialization filter tightened
The default `ObjectInputFilter` pattern that ships with the components listed below has been tightened
-to explicitly deny classes under `java.net.**` before allowing the rest of `java.**`, `javax.**` and
-`org.apache.camel.**`. The previous default did not deny `java.net.**`, which meant classes whose
+to explicitly deny classes under `+java.net.**+` before allowing the rest of `+java.**+`, `+javax.**+` and
+`+org.apache.camel.**+`. The previous default did not deny `+java.net.**+`, which meant classes whose
`hashCode`/`equals` methods perform network I/O (notably `java.net.URL` and `java.net.InetAddress`)
could be deserialized by the in-code default.
@@ -446,8 +446,8 @@ The new default is:
!java.net.**;java.**;javax.**;org.apache.camel.**;!*
----
-(or `!java.net.**;java.**;org.apache.camel.**;!*` for the aggregation repository components, which
-do not include `javax.**`).
+(or `+!java.net.**;java.**;org.apache.camel.**;!*+` for the aggregation repository components, which
+do not include `+javax.**+`).
The endpoint-level option `deserializationFilter` and the JVM-wide system property
`-Djdk.serialFilter` continue to override this default. Applications that have a legitimate need to
@@ -1018,12 +1018,12 @@ without changes. Routes that set the headers by their literal string value
Because the renamed prefixes now begin with `Camel`, they are stripped by the
standard transport `HeaderFilterStrategy` (`HttpHeaderFilterStrategy`, etc.)
-when crossing a transport boundary, by design — `Camel*` headers are
+when crossing a transport boundary, by design — `+Camel*+` headers are
framework-internal and are not propagated over the wire. Routes that bridge an
external transport (HTTP, JMS, ...) into a `solr:` producer and want to drive
Solr document fields or query parameters from a header supplied by the sender
must therefore carry the value in a non-`Camel`-prefixed application header and
-map it to the appropriate `CamelSolrField.*` / `CamelSolrParam.*` header in the
+map it to the appropriate `+CamelSolrField.*+` / `+CamelSolrParam.*+` header in the
route between the transport `from` and the `solr:` `to`.
=== camel-aws2-s3
@@ -1079,8 +1079,8 @@ The HTTP components (which share `camel-http-common`) now apply a Java deseriali
`allowJavaSerializedObject` / `transferException` path, aligning them with `camel-netty-http`, `camel-jms`
and `camel-vertx-http`. A new `deserializationFilter` component option (same syntax as `jdk.serialFilter`)
can be set to customise it; when unset, the JVM-wide `jdk.serialFilter` is used if present, otherwise a
-conservative default filter (denying `java.net.**`, allowing `java.**` / `javax.**` /
-`org.apache.camel.**`, with JEP-290 graph-shape limits) is applied. This is a defense-in-depth measure on
+conservative default filter (denying `+java.net.**+`, allowing `+java.**+` / `+javax.**+` /
+`+org.apache.camel.**+`, with JEP-290 graph-shape limits) is applied. This is a defense-in-depth measure on
an already opt-in path; a serialized payload that was accepted before may now be rejected if it references
a denied class.
@@ -1485,9 +1485,9 @@ effect from 4.22.0 onwards; see the
entry in the 4.21 to 4.22 upgrade guide.
====
-`UndertowHeaderFilterStrategy` now also filters the legacy `websocket.*`
-Exchange-header prefix (in addition to the `Camel*` / `camel*` /
-`org.apache.camel.*` prefixes it already filtered). This applies to both the
+`UndertowHeaderFilterStrategy` now also filters the legacy `+websocket.*+`
+Exchange-header prefix (in addition to the `+Camel*+` / `+camel*+` /
+`+org.apache.camel.*+` prefixes it already filtered). This applies to both the
in (wire -> exchange) and out (exchange -> wire) directions and follows the
dedicated-filter-strategy shape used by CAMEL-23532 for
`camel-vertx-websocket` / `camel-atmosphere-websocket` / `camel-iggy`.
@@ -2154,10 +2154,10 @@ headers and are unchanged.
`KafkaConstants.OVERRIDE_TOPIC` and `KafkaConstants.OVERRIDE_TIMESTAMP` are
producer-read headers consulted by `KafkaProducer.evaluateTopic()` and the
timestamp override path. The rename also closes the cross-transport
-propagation gap where these headers, in their previous `kafka.*` form,
+propagation gap where these headers, in their previous `+kafka.*+` form,
would pass through `HttpHeaderFilterStrategy` (which only filters the
`Camel` prefix) on an upstream HTTP / REST consumer wired to a Kafka
-producer in the same route. With the new `CamelKafka*` values, the default
+producer in the same route. With the new `+CamelKafka*+` values, the default
filter strategy strips them at the transport boundary.
Routes that reference the constants symbolically (for example
@@ -2238,7 +2238,7 @@ at the old filenames; routes referencing the dataformats by `name` are unaffecte
=== camel-platform-http-main
-Two new optional configuration properties are available on both `camel.server.*` and `camel.management.*`
+Two new optional configuration properties are available on both `+camel.server.*+` and `+camel.management.*+`
for the embedded HTTP server:
* `jwtIssuer` — when set, validates the `iss` (issuer) claim of incoming JWT tokens.
@@ -2389,9 +2389,9 @@ The in-code default `ObjectInputFilter` shipped by the following components now
The new defaults are:
-* `!java.net.**;java.**;javax.**;org.apache.camel.**;maxdepth=20;maxrefs=10000;maxbytes=10485760;!*`
+* `+!java.net.**;java.**;javax.**;org.apache.camel.**;maxdepth=20;maxrefs=10000;maxbytes=10485760;!*+`
(camel-infinispan, camel-mina, camel-netty, camel-netty-http, camel-vertx-http)
-* `!java.net.**;java.**;org.apache.camel.**;maxdepth=20;maxrefs=10000;maxbytes=10485760;!*`
+* `+!java.net.**;java.**;org.apache.camel.**;maxdepth=20;maxrefs=10000;maxbytes=10485760;!*+`
(camel-leveldb, camel-cassandraql, camel-consul, camel-sql)
These limits provide defense-in-depth so that operators who have not set `-Djdk.serialFilter` still get
diff --git a/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_22.adoc b/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_22.adoc
index 565d85c70ada..a964fb36ea5b 100644
--- a/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_22.adoc
+++ b/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_22.adoc
@@ -1943,8 +1943,8 @@ from("direct:next")
----
The sibling websocket components are not affected by this change: `camel-undertow`
-keeps the `websocket.*` values in `UndertowConstants` (as documented in the 4.18
-upgrade guide), and `camel-vertx-websocket` keeps its `CamelVertxWebsocket.*` values.
+keeps the `+websocket.*+` values in `UndertowConstants` (as documented in the 4.18
+upgrade guide), and `camel-vertx-websocket` keeps its `+CamelVertxWebsocket.*+` values.
Note that `WebsocketConstants.SEND_TO_ALL` is not read by this component. Broadcast is
selected through the `sendToAll` endpoint option, not through the header; the constant
diff --git a/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_23.adoc b/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_23.adoc
index b87d2913d5d9..e8836d94d130 100644
--- a/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_23.adoc
+++ b/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_23.adoc
@@ -700,7 +700,7 @@ the Camel message. That strategy filters the `mail.smtp.` and `mail.smtps.` pref
path in addition to `Camel*`/`camel*`, so the data format now filters the same namespace the mail
consumer has filtered since 4.14.9/4.18.4/4.22.0.
-Routes that relied on `mail.smtp.*` or `mail.smtps.*` headers arriving on the exchange from an
+Routes that relied on `+mail.smtp.*+` or `+mail.smtps.*+` headers arriving on the exchange from an
unmarshalled MIME message must set those values explicitly on the route instead. Ordinary
application headers are unaffected.
@@ -1037,8 +1037,8 @@ when an endpoint is created, so existing subclasses continue to behave as before
=== camel-jetty
`enableCORS=true` added `new CrossOriginFilter()` with no init parameters, so Jetty's own defaults
-applied: `allowedOrigins=*` together with `allowCredentials=true`. Since the filter reflects the request's
-origin rather than sending `*`, that is the credentialed any-origin configuration the fetch specification
+applied: `+allowedOrigins=*+` together with `allowCredentials=true`. Since the filter reflects the request's
+origin rather than sending `+*+`, that is the credentialed any-origin configuration the fetch specification
refuses to express — reflecting the origin being the usual way around that rule. An option named "enable
CORS" should not mean "every origin, with credentials".
@@ -1653,10 +1653,10 @@ system property, or inject it from an external secret store.
==== Starter configuration options that cannot be bound are reported
-The starters bind `camel.component.*`, `camel.dataformat.*` and `camel.language.*` onto the Camel component,
+The starters bind `+camel.component.*+`, `+camel.dataformat.*+` and `+camel.language.*+` onto the Camel component,
data format or language they configure. Two steps of that binding used to discard a configured value without
reporting it, so a mistyped or unbindable option left the target at its default and nothing appeared in the
-log. Both now report the value they cannot use, which matches what `camel.rest.*` has always done.
+log. Both now report the value they cannot use, which matches what `+camel.rest.*+` has always done.
An option of a complex (object) type is configured with a reference to a bean, such as:
@@ -1665,11 +1665,11 @@ An option of a complex (object) type is configured with a reference to a bean, s
camel.component.http.ssl-context-parameters = #bean:mySslContextParameters
----
-The generated converter used to return `null` for any value that did not start with `#`, and for a value
+The generated converter used to return `null` for any value that did not start with `+#+`, and for a value
naming a bean that does not exist. A typo in the bean id therefore produced a component with the option
unset. Such a value now aborts startup with a message naming the value, the target type and the
-configuration prefix it was set under. A plain bean id with no `#` prefix — `mySslContextParameters` — is
-resolved rather than discarded, as are `#autowired` and `#type:com.foo.MyType`.
+configuration prefix it was set under. A plain bean id with no `+#+` prefix — `mySslContextParameters` — is
+resolved rather than discarded, as are `+#autowired+` and `+#type:com.foo.MyType+`.
These converters are registered with `@ConfigurationPropertiesBinding` and therefore take part in every
`@ConfigurationProperties` binding in the application, not only in Camel's own. A binding whose target class
diff --git a/docs/user-manual/modules/ROOT/pages/camel-jbang-mcp.adoc b/docs/user-manual/modules/ROOT/pages/camel-jbang-mcp.adoc
index 7d7547aa00e6..daed2838a27d 100644
--- a/docs/user-manual/modules/ROOT/pages/camel-jbang-mcp.adoc
+++ b/docs/user-manual/modules/ROOT/pages/camel-jbang-mcp.adoc
@@ -186,7 +186,7 @@ The assistant discovers components, looks up documentation, builds a YAML route,
=== Validation
-* _"Validate this endpoint: `kafka:myTopic?brkers=localhost:9092`"_ — detects the typo and suggests `brokers`
+* _"Validate this endpoint: ``kafka:myTopic?brkers=localhost:9092``"_ — detects the typo and suggests `brokers`
* _"Validate this YAML route"_ — checks against the YAML DSL JSON schema, reports invalid elements
=== Understanding, security, and testing
diff --git a/docs/user-manual/modules/ROOT/pages/camel-jbang-tui.adoc b/docs/user-manual/modules/ROOT/pages/camel-jbang-tui.adoc
index 730c49973b5c..c44e615e4382 100644
--- a/docs/user-manual/modules/ROOT/pages/camel-jbang-tui.adoc
+++ b/docs/user-manual/modules/ROOT/pages/camel-jbang-tui.adoc
@@ -174,7 +174,7 @@ right panel with full syntax highlighting.
For Camel source files (YAML, XML, Java routes, and `application.properties`), press *i* to toggle
inline documentation. The TUI uses the Camel catalog to look up every component, EIP, language,
and data format used in your route and shows their documentation right next to the source code.
-For properties files, it resolves `camel.component.*` and `camel.main.*` keys to their catalog
+For properties files, it resolves `+camel.component.*+` and `+camel.main.*+` keys to their catalog
descriptions. This makes it easy to understand unfamiliar routes without leaving the terminal.
Additional features:
@@ -200,8 +200,8 @@ Camel routes:
* *Word navigation* -- *Ctrl+Left/Right* to jump by word
* *Smart Home* -- *Home* key alternates between content indent and column 0
* *Tab completion* -- press *Tab* for context-aware completion:
-** In `application.properties`: Camel configuration options (`camel.main.*`, `camel.component.*`, etc.)
- and Spring Boot auto-configuration properties (`server.*`, `spring.*`, `management.*`, etc.)
+** In `application.properties`: Camel configuration options (`+camel.main.*+`, `+camel.component.*+`, etc.)
+ and Spring Boot auto-configuration properties (`+server.*+`, `+spring.*+`, `+management.*+`, etc.)
resolved from starter JARs in the local Maven repository — works even for stopped projects
** In YAML DSL routes: EIP names, component URIs, option keys and values
@@ -931,7 +931,7 @@ returns that section only; pass `sections` to list what the document contains. S
When the AI panel is open, input that starts with `/` runs a local panel command instead of sending a question to the configured AI provider. `/provider` and `/model` are unavailable while a response or command is already in progress; the panel shows a message asking you to wait.
-Press *Tab* to complete a command name. After `/model ` *Tab* completes the model name against the
+Press *Tab* to complete a command name. After `++/model ++` *Tab* completes the model name against the
models the current provider reports (the list is fetched in the background on the first press, so
press *Tab* again once it has arrived), and after `/tools ` it completes `auto`, `core` or `full`.
With several matches *Tab* fills in the common prefix and then cycles through them; *Shift+Tab*
diff --git a/docs/user-manual/modules/ROOT/pages/security-model.adoc b/docs/user-manual/modules/ROOT/pages/security-model.adoc
index 6245a25b1ced..35cb0904133f 100644
--- a/docs/user-manual/modules/ROOT/pages/security-model.adoc
+++ b/docs/user-manual/modules/ROOT/pages/security-model.adoc
@@ -228,7 +228,7 @@ which protective property it breaks.
| Critical (CVSS 9.0-10.0)
| Untrusted data cannot redirect the route to a different endpoint, bean, method or command
-| A control header injected from the wire changes where the exchange is dispatched, which operation runs, or which transport and credentials are used - whether it is spelled inside the internal namespace (`CamelBeanMethodName`, `CamelExecCommandExecutable`, `CamelHttpUri`, `CamelJmsDestinationName`, ...) or outside it (`websocket.connectionKey`, `gridfs.*`, `irc.sendTo`, `operationName`, `mail.smtp.*`, ...)
+| A control header injected from the wire changes where the exchange is dispatched, which operation runs, or which transport and credentials are used - whether it is spelled inside the internal namespace (`CamelBeanMethodName`, `CamelExecCommandExecutable`, `CamelHttpUri`, `CamelJmsDestinationName`, ...) or outside it (`websocket.connectionKey`, `+gridfs.*+`, `irc.sendTo`, `operationName`, `+mail.smtp.*+`, ...)
| Critical (CVSS 9.0-9.8)
| Untrusted data is never deserialised into arbitrary Java types
@@ -319,11 +319,11 @@ against core code, and the triager needs the core-side statement to judge it.
| Out of scope (no engine guarantee)
|===
-A candidate located in a `core/camel-*` module is judged against these
+A candidate located in a `+core/camel-*+` module is judged against these
invariants first. If the engine upheld the invariant and the violation arises
only because a route author authored an expression or route over untrusted
input, or wired an untrusted source straight through without
-`removeHeaders("Camel*")`, the disposition is the route-author position in
+`+removeHeaders("Camel*")+`, the disposition is the route-author position in
_Out of scope_, not a framework vulnerability - the same line the rest of this
model draws between the route plus its configuration and the data flowing
through it.
@@ -422,14 +422,14 @@ the misunderstanding can be closed against the correct contract.
does not, and cannot, strip the application-level headers a component
reads as semantic input. Route authors who need application-header
sanitisation must do it explicitly at the trust boundary.
-* *`removeHeaders("Camel*")` strips the internal-dispatch headers, not
+* *`+removeHeaders("Camel*")+` strips the internal-dispatch headers, not
every untrusted-origin header.* It is the recommended trust-boundary
hygiene against the internal-header dispatch class (see _Deployment
hardening_), and it is necessary; it is not, on its own, sufficient
to sanitise the application headers a downstream component will trust.
It also does not match a control header spelled outside the namespace -
- `websocket.connectionKey`, `gridfs.*`, `irc.sendTo`, `operationName`,
- `mail.smtp.*`. Those are the framework's responsibility to filter and
+ `websocket.connectionKey`, `+gridfs.*+`, `irc.sendTo`, `operationName`,
+ `+mail.smtp.*+`. Those are the framework's responsibility to filter and
have been fixed as advisories where they were reachable, but a route
running against a release that predates the relevant fix needs the
namespace stripped explicitly as well.
@@ -619,7 +619,7 @@ it is called, when it selects any of:
CVE-2026-46453 `camel-elasticsearch-rest-client`);
* *the transport or its credentials* - which host, protocol, TLS posture or
authentication the component uses (CVE-2026-46584 `camel-mail`, where
- attacker-supplied `mail.smtp.*` / `mail.smtps.*` headers were applied as
+ attacker-supplied `+mail.smtp.*+` / `+mail.smtps.*+` headers were applied as
JavaMail session properties, weakening SMTP transport security and, before
4.19.0, redirecting the connection and disclosing the configured
credentials).
@@ -648,7 +648,7 @@ needs an effective strategy:
headers of the message being unmarshalled onto the `Exchange` with no
filter at all. CAMEL-24419 then showed the second half of the lesson - the
data format had been given a plain `DefaultHeaderFilterStrategy`, which
- knows only `Camel*` / `camel*`, so the `mail.smtp.*` namespace that the
+ knows only `+Camel*+` / `+camel*+`, so the `+mail.smtp.*+` namespace that the
*consumer* path deliberately filters was still admitted through the
unmarshal path. An entry point that filters a narrower namespace than its
sibling entry point is a gap, not a difference in configuration.
@@ -677,19 +677,19 @@ outcome. Presence of a defence in the source is not evidence that it executes;
both the reporter and the triager have to establish that the guard is on the
live path.
-The prefixed headers of the API-based components - `CamelFhir.*`,
-`CamelBox.*`, `CamelOlingo4.*`, `CamelAs2.*` and the other
+The prefixed headers of the API-based components - `+CamelFhir.*+`,
+`+CamelBox.*+`, `+CamelOlingo4.*+`, `+CamelAs2.*+` and the other
`camel-api-component` generated producers, which select the API method and its
-arguments - sit inside the `Camel*` namespace, so they are governed by exactly
-this rule. The project's position on a `Camel<Api>.*` header reaching an API
+arguments - sit inside the `+Camel*+` namespace, so they are governed by exactly
+this rule. The project's position on a `+Camel<Api>.*+` header reaching an API
producer from an untrusted source is therefore *conditional, and the condition
is at the inbound consumer, not at the API producer*; it is not "always out of
-scope". A consumer that admits a `Camel<Api>.*` header from an untrusted source
-without an effective case-insensitive `Camel*` `HeaderFilterStrategy` is in
+scope". A consumer that admits a `+Camel<Api>.*+` header from an untrusted source
+without an effective case-insensitive `+Camel*+` `HeaderFilterStrategy` is in
scope regardless of which producer ultimately consumes the header - this is the
same class as the CVE-2025-27636 family. The API producer honouring a
-`Camel<Api>.*` header that reached it only because a route author wired an
-untrusted source straight to the producer without `removeHeaders("Camel*")`,
+`+Camel<Api>.*+` header that reached it only because a route author wired an
+untrusted source straight to the producer without `+removeHeaders("Camel*")+`,
while the inbound filter was in place and effective, is the documented
bean-dispatch contract (see _Known limitations_), not a framework
vulnerability.
@@ -1021,7 +1021,7 @@ they are, the change is announced through the normal upgrade-guide channel.
side the inbound `Camel*` `HeaderFilterStrategy` is applied by default since
4.21 (CAMEL-23543), and component authors must not opt out of it.
* *The framework's automatic header filtering is scoped to the internal
- `Camel*` namespace.* Since 4.21 (CAMEL-23543) `DefaultHeaderFilterStrategy`
+ `+Camel*+` namespace.* Since 4.21 (CAMEL-23543) `DefaultHeaderFilterStrategy`
filters that namespace case-insensitively *by default, in both directions,
for every consumer and producer that uses it*, with no per-component
configuration; it does not, and cannot, filter
@@ -1094,7 +1094,7 @@ Disposition is `KNOWN-NON-FINDING` (see _Triage dispositions_).
reference allows RCE."* These are route-author primitives by design.
Route code is trusted code; see the route-author entry in _Out of
scope_ and the route-author row in _Roles_.
-* *"A `Camel*` header controls dispatch, therefore
+* *"A `+Camel*+` header controls dispatch, therefore
the consumer is vulnerable."* Bean-based dispatch via internal headers
is the public contract for letting a route control component behaviour;
see the second bullet under _Known limitations_. A finding is in scope
@@ -1118,8 +1118,8 @@ Disposition is `KNOWN-NON-FINDING` (see _Triage dispositions_).
it is a control header, it is in scope however it is spelled, and the
disposition is not `KNOWN-NON-FINDING` - see the control-header
definition under the Camel-header class in _In-scope vulnerability
- classes_, and the advisories cited there for `websocket.*`, `gridfs.*`,
- `irc.*`, `operationName` and `mail.smtp.*`. The absence of a `Camel`
+ classes_, and the advisories cited there for `+websocket.*+`, `+gridfs.*+`,
+ `+irc.*+`, `operationName` and `+mail.smtp.*+`. The absence of a `Camel`
prefix decides nothing on its own.
* *"`DefaultHeaderFilterStrategy` can be bypassed by changing the case
(`caMEL`, `CAMEL`)."* The default strategy is case-insensitive out of
@@ -1179,11 +1179,11 @@ Disposition is `KNOWN-NON-FINDING` (see _Triage dispositions_).
enables an unsafe behaviour."* Documented opt-ins; the operator has
explicitly accepted the consequence. See the explicit-opt-in entry in
_Out of scope_.
-* *"A finding lands in a `core/camel-*` module."* Routed first against
+* *"A finding lands in a `+core/camel-*+` module."* Routed first against
_Core router-engine invariants_. If the engine upheld every listed
invariant and the violation arises only because a route author
authored an expression or route over untrusted input, or wired an
- untrusted source straight through without `removeHeaders("Camel*")`,
+ untrusted source straight through without `+removeHeaders("Camel*")+`,
the disposition is the route-author position in _Out of scope_.
=== Triage dispositions
@@ -1463,13 +1463,13 @@ YAML::
----
====
* *On older releases, also strip the control-header namespaces of the
- components in the route.* The framework filters the `Camel*` namespace by
+ components in the route.* The framework filters the `+Camel*+` namespace by
default and has fixed the non-prefixed control headers it shipped
- (`websocket.*`, `gridfs.*`, `irc.*`, `operationName`, `mail.smtp.*`) as
+ (`+websocket.*+`, `+gridfs.*+`, `+irc.*+`, `operationName`, `+mail.smtp.*+`) as
those were found; each fix names its affected and fixed versions in the
corresponding advisory at link:/security/[]. Where a deployment cannot yet
move to a release that carries them, add the relevant prefixes to the
- `removeHeaders` pattern at the trust boundary alongside `Camel*`.
+ `removeHeaders` pattern at the trust boundary alongside `+Camel*+`.
* *Do not enable Java serialisation on consumers exposed to untrusted
networks.* In particular, do not set `allowJavaSerializedObject=true`,
`transferException=true`, or `mapJmsMessage=true` on a JMS consumer when the
diff --git a/dsl/camel-yaml-dsl/camel-yaml-dsl/src/main/docs/yaml-dsl.adoc b/dsl/camel-yaml-dsl/camel-yaml-dsl/src/main/docs/yaml-dsl.adoc
index 6773f8a975c4..e8d9b667269a 100644
--- a/dsl/camel-yaml-dsl/camel-yaml-dsl/src/main/docs/yaml-dsl.adoc
+++ b/dsl/camel-yaml-dsl/camel-yaml-dsl/src/main/docs/yaml-dsl.adoc
@@ -837,7 +837,7 @@ a simpler, more predictable schema structure. The classic schema remains the def
=== Using the schemas with IDEs
The classic schema is registered in the https://www.schemastore.org/[JSON Schema Store] and is automatically
-used by IDEs like VS Code and IntelliJ for files matching `*.camel.yaml` and `*.camelk.yaml`.
+used by IDEs like VS Code and IntelliJ for files matching `+*.camel.yaml+` and `+*.camelk.yaml+`.
To use the canonical schema instead, configure your IDE to point to the canonical schema URL: