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 1329fb2fbe29 CAMEL-23526: docs - sync camel-cxf 4.14 upgrade-guide
entry to main (#23377)
1329fb2fbe29 is described below
commit 1329fb2fbe29f5099281706e5d293de802318436
Author: Andrea Cosentino <[email protected]>
AuthorDate: Thu May 21 10:20:34 2026 +0200
CAMEL-23526: docs - sync camel-cxf 4.14 upgrade-guide entry to main (#23377)
Mirrors the `=== camel-cxf` entry added by the backport
(apache/camel#23376) into `camel-4x-upgrade-guide-4_14.adoc` on main, so the
canonical multi-version upgrade-guide history on main stays in sync with the
camel-4.14.x maintenance branch. Documents the constant rename
(operationName / operationNamespace -> CamelCxfOperationName /
CamelCxfOperationNamespace), the cxfrs SimpleConsumer dispatch-idiom change,
and the cross-transport propagation behaviour change.
Per CLAUDE.md's backport upgrade-guide policy.
Reported by Claude Code on behalf of Andrea Cosentino
Signed-off-by: Andrea Cosentino <[email protected]>
---
.../ROOT/pages/camel-4x-upgrade-guide-4_14.adoc | 74 ++++++++++++++++++++++
1 file changed, 74 insertions(+)
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 d2ebf014e3f7..ed843ccc9bbd 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
@@ -344,3 +344,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.
