Repository navigation
[backport camel-4.22.x] CAMEL-25895: camel-openstack - align the remaining Swift header constants with the Camel naming convention - #28280
Conversation
…ants with the Camel naming convention CAMEL-23580 renamed the camel-openstack Exchange header constants to the CamelOpenstack* convention, but left four of them in SwiftConstants on their openstack4j values, on the understanding that those values are part of the Swift HTTP contract: CONTAINER_METADATA_PREFIX X-Container-Meta- -> CamelOpenstackSwiftContainerMetadata VERSIONS_LOCATION X-Versions-Location -> CamelOpenstackSwiftVersionsLocation CONTAINER_READ X-Container-Read -> CamelOpenstackSwiftContainerRead CONTAINER_WRITE X-Container-Write -> CamelOpenstackSwiftContainerWrite They are not. ContainerProducer passes the values to the openstack4j CreateUpdateContainerOptions, which builds the X-Container-Meta-, X-Versions-Location, X-Container-Read and X-Container-Write names of the Swift request itself, so the Exchange header key never reaches Swift and the request on the wire is unchanged by this rename. This commit therefore partly reverses the decision taken in CAMEL-23580, because the reason recorded for it does not hold. The Java field names are unchanged, so routes that reference the constants symbolically keep working. Routes that set one of these headers by its literal string value must move to the new value. ContainerProducerTest had no coverage of the container options path at all; six tests are added for it. Backport of apache#28231. The upgrade-guide note for this release line and the design/headers.adoc correction stay on main, where the project keeps the upgrade guides for every version. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Signed-off-by: Zineb Bendhiba <bendhiba.zineb@gmail.com>
gnodet-bot
left a comment
There was a problem hiding this comment.
Clean mechanical backport of the reviewed PR (#28231). The code is byte-identical to main per the PR claim, the 4 omitted doc files are consistent with Camel's backport convention (upgrade guides live on main), and the 6 new tests provide valid coverage.
The test containerUpdateIgnoresThePreviousSwiftHeaderNames is the most important test: proves old wire header names are now silently ignored. Worth confirming companion upgrade-guide PR on main exists before 4.22.3 release.
This review was generated by an AI agent, Hermès on behalf of @gnodet.
davsclaus
left a comment
There was a problem hiding this comment.
Thanks Zineb. I diffed this backport against #28231: the changed lines in SwiftConstants, ContainerProducerTest, the component JSON, the catalog JSON and the endpoint DSL are the same, so this is a straight cherry-pick. The upgrade-guide changes stay on main, where #28231 already put them. Approving, to merge once CI is green.
Claude Code on behalf of @davsclaus.
This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.
|
🌟 Thank you for your contribution to the Apache Camel project! 🌟 🐫 Apache Camel Committers, please review the following items:
|
Backport of #28231 to
camel-4.22.xCherry-pick of #28231 (
3ef68e407da3) ontocamel-4.22.x, shipping in 4.22.3.What this carries
The five functional files of the original commit, applied with no change:
SwiftConstants.javaCamelOpenstackSwift*valuesContainerProducerTest.javaopenstack-swift.json(component + catalog)SwiftEndpointBuilderFactory.javaThe Java field names are unchanged, so routes using the constants symbolically keep working. The request Camel
sends to Swift is unchanged: openstack4j builds the
X-Container-*wire names itself fromCreateUpdateContainerOptions, so the Exchange header key never reaches Swift.What this does not carry, and why
The original commit also touched
design/headers.adocand three upgrade guides. None of them is carried here:the project keeps the upgrade guides for every version on
main, where they act as the canonical historyacross releases.
design/headers.adocdoes exist on this branch, but the design notes are kept onmainfor thesame reason.
The 4.22.3 upgrade-guide note is added on
maininstead, in the companion PR, under== Upgrading from 4.22.2 to 4.22.3.Mechanical-port check
The code is a byte-identical port: the resulting
ContainerProducerTest.javais identical tomain,ContainerProducer.javais identical on this branch and onmain, and the changeset is identical to thecamel-4.18.x/camel-4.22.xsibling backport. The only conflict resolution was removing the doc files thatdo not exist on this branch, so a
gh pr diffcomparison against #28231 will show those doc hunks as thedifference. No reviewers are requested, per the project's backport rule; the code went through review on #28231.