This is an automated email from the ASF dual-hosted git repository.
oscerd 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 5dc27564aabd CAMEL-23526: docs - sync camel-cxf 4.18 upgrade-guide
entry to main (#23370)
5dc27564aabd is described below
commit 5dc27564aabd21d1853bca4f9ca889ad517c7324
Author: Andrea Cosentino <[email protected]>
AuthorDate: Wed May 20 15:08:10 2026 +0200
CAMEL-23526: docs - sync camel-cxf 4.18 upgrade-guide entry to main (#23370)
Mirrors the camel-cxf entry added by the backport apache/camel#23369 into
camel-4x-upgrade-guide-4_18.adoc on main, so main's canonical multi-version
upgrade-guide history stays in sync with camel-4.18.x.
Documents on main's 4_18.adoc:
- Constant rename in CxfConstants: operationName / operationNamespace ->
CamelCxfOperationName / CamelCxfOperationNamespace
- The cxfrs SimpleConsumer dispatch-idiom change
- The cross-transport propagation behaviour change (transport
HeaderFilterStrategy filters Camel* headers; route must restore the
operation header after a transport hop)
Per CLAUDE.md's backport upgrade-guide policy.
Reported by Claude Code on behalf of Andrea Cosentino
---
.../ROOT/pages/camel-4x-upgrade-guide-4_18.adoc | 74 ++++++++++++++++++++++
1 file changed, 74 insertions(+)
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 868760fd1aa4..e23a680c3818 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
@@ -566,3 +566,77 @@ outbound regex. Headers starting with `Camel` / `camel`
(case-insensitive), `bre
component with the rest of the Camel component catalog. Routes that relied on
receiving these
header names on inbound SNS messages can supply a custom
`headerFilterStrategy` to restore the
previous behaviour.
+
+=== camel-cxf
+
+The Exchange header constants in `CxfConstants` (module `camel-cxf-common`,
shared
+by `camel-cxf` and `camel-cxfrs`) have been renamed to follow the Camel naming
+convention used across the rest of the component catalog. The Java field names
are
+unchanged; only the header string values have changed:
+
+[options="header"]
+|===
+| Constant | Previous value | New value
+| `CxfConstants.OPERATION_NAME` | `operationName` | `CamelCxfOperationName`
+| `CxfConstants.OPERATION_NAMESPACE` | `operationNamespace` |
`CamelCxfOperationNamespace`
+|===
+
+Routes that reference the constant symbolically (for example
+`setHeader(CxfConstants.OPERATION_NAME, ...)`) continue to work without
changes.
+Routes that set the header by its literal string value (for example
+`setHeader("operationName", ...)`) must be updated to use the new value
+(`setHeader("CamelCxfOperationName", ...)`).
+
+In particular, the documented `cxfrs` `SimpleConsumer` dispatch idiom that
routes
+on the operation name by its literal header name must be updated:
+
+[source,java]
+----
+// before
+from("cxfrs:bean:rsServer?bindingStyle=SimpleConsumer")
+ .recipientList(simple("direct:${header.operationName}"));
+
+// after
+from("cxfrs:bean:rsServer?bindingStyle=SimpleConsumer")
+ .recipientList(simple("direct:${header.CamelCxfOperationName}"));
+----
+
+==== Behaviour change: cross-transport propagation of the operation header
+
+Because the renamed header value now begins with `Camel`, it is filtered by the
+standard transport `HeaderFilterStrategy` (`JmsHeaderFilterStrategy`,
+`HttpHeaderFilterStrategy`, etc.) 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 (JMS, HTTP, ...) into a `cxf:`
producer
+and select the SOAP operation from a header supplied by the sender must
+therefore carry the operation in a non-`Camel`-prefixed application header and
+map it to `CxfConstants.OPERATION_NAME` (`CamelCxfOperationName`) in the route
+between the transport `from` and the `cxf:` `to`:
+
+[source,xml]
+----
+<!-- before -->
+<route>
+ <from uri="jms:queue:bridge.cxf"/>
+ <to uri="cxf://bean:serviceEndpoint"/>
+</route>
+<!-- caller sets the header keyed by the pre-rename value:
+ setHeader("operationName", "greetMe") -->
+
+<!-- after -->
+<route>
+ <from uri="jms:queue:bridge.cxf"/>
+ <setHeader name="CamelCxfOperationName">
+ <simple>${header.operationName}</simple>
+ </setHeader>
+ <to uri="cxf://bean:serviceEndpoint"/>
+</route>
+<!-- caller sets a non-Camel-prefixed application carrier header (any name
+ that is not stripped by the transport HeaderFilterStrategy works);
+ the route restores the CXF operation header after the transport hop. -->
+----
+
+The same pattern applies to HTTP-based bridges (`platform-http`/`jetty`/`netty
+-http`/`http` -> `cxf:`) and any other transport whose default
+`HeaderFilterStrategy` filters `Camel*` headers.
