Repository navigation
[backport camel-4.18.x] CAMEL-25895: camel-openstack - align the remaining Swift header constants with the Camel naming convention - #28281
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>
zbendhiba
added
components
bug
gnodet-bot
left a comment
gnodet-bot
left a comment
There was a problem hiding this comment.
LGTM. Clean byte-identical backport of the SwiftConstants rename from #28231. The constant values, tests, and generated artifacts are all consistent. The six new tests correctly exercise the renamed headers through ContainerProducer — in particular containerUpdateIgnoresThePreviousSwiftHeaderNames confirms the old wire-format names no longer match. No issues found.
This review was generated by an AI agent, Hermès on behalf of @gnodet.
davsclaus
left a comment
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.
|
The failure is unrelated to this changeset. Maven Central returned a 500 on |
4 participants
Backport of #28231 to
camel-4.18.xCherry-pick of #28231 (
3ef68e407da3) ontocamel-4.18.x, shipping in 4.18.6.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.adocand the 4.21 and 4.24 upgrade guides do not exist on this branch at all.The 4.18.6 upgrade-guide note is added on
maininstead, in the companion PR, under== Upgrading from 4.18.5 to 4.18.6.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.