Zineb Bendhiba created CAMEL-25895:
--------------------------------------
Summary: camel-openstack - use Camel-prefixed names for the
remaining Swift headers
Key: CAMEL-25895
URL: https://issues.apache.org/jira/browse/CAMEL-25895
Project: Camel
Issue Type: Bug
Components: camel-openstack
Reporter: Zineb Bendhiba
Assignee: Zineb Bendhiba
Fix For: 4.24.0, 4.22.3, 4.18.6
h3. Today
CAMEL-23580 renamed the Swift Exchange header constants in {{camel-openstack}}
to
the {{CamelOpenstackSwift*}} naming convention used across the component, but
four constants in {{SwiftConstants}} were left with the raw openstack4j wire
names:
* {{CONTAINER_READ}} = {{X-Container-Read}}
* {{CONTAINER_WRITE}} = {{X-Container-Write}}
* {{VERSIONS_LOCATION}} = {{X-Versions-Location}}
* {{CONTAINER_METADATA_PREFIX}} = {{X-Container-Meta-}}
The code comment above them states that renaming them would break
interoperability with the Swift API. That rationale is incorrect: openstack4j
builds the wire headers itself. {{CreateUpdateContainerOptions.accessRead(..)}},
{{accessWrite(..)}} and {{versionsLocation(..)}} emit {{X-Container-Read}} /
{{X-Container-Write}} / {{X-Versions-Location}} from their own
{{SwiftHeaders}} constants, so the Camel Exchange key never reaches Swift and
the Camel-side name is free to follow the project convention.
Two consequences follow. The recorded reason for the exception does not hold, so
the comment misleads the next reader. And {{openstack-swift}} is left as the
only
component in the family whose Exchange keys are partly un-prefixed, which means
these four keys do not behave like every other Camel header with respect to the
default header filter strategies. {{camel-aws2-s3}}, for instance, already uses
{{CamelAwsS3Acl}} and {{CamelAwsS3CannedAcl}} rather than the S3 wire names.
h3. After the change
All Swift Exchange header names carry the {{CamelOpenstackSwift}} prefix, so the
whole component is consistent and the four keys are filtered like every other
Camel header. The misleading comment is gone.
h3. Classes involved
*
{{components/camel-openstack/src/main/java/org/apache/camel/component/openstack/swift/SwiftConstants.java}}
*
{{components/camel-openstack/src/main/java/org/apache/camel/component/openstack/swift/producer/ContainerProducer.java}}
h3. Code-level change
* In {{SwiftConstants}}, change the four constant *values*:
** {{CONTAINER_READ}} -> {{CamelOpenstackSwiftContainerRead}}
** {{CONTAINER_WRITE}} -> {{CamelOpenstackSwiftContainerWrite}}
** {{VERSIONS_LOCATION}} -> {{CamelOpenstackSwiftVersionsLocation}}
** {{CONTAINER_METADATA_PREFIX}} -> {{CamelOpenstackSwiftContainerMetadata}}
* Keep the Java field names as they are, so routes referencing the constants
symbolically keep compiling. ({{CONTAINER_METADATA_PREFIX}} is read as a whole
{{Map}} and never as a prefix, so a follow-up rename of that field, with the
old one kept as a deprecated alias, can be considered separately.)
* Remove the now-incorrect comment block that justified keeping the wire names,
and the unused {{org.openstack4j.model.storage.object.SwiftHeaders}} import.
* {{ContainerProducer.messageToCreateUpdateOptions(..)}} already reads the
constants rather than string literals, so it needs no structural change; a
grep over the module confirms no other place uses the raw strings.
* Regenerate and commit the generated artefacts, since CI fails on uncommitted
changes:
**
{{components/camel-openstack/src/generated/resources/META-INF/org/apache/camel/component/openstack/swift/openstack-swift.json}}
**
{{catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/components/openstack-swift.json}}
**
{{dsl/camel-endpointdsl/src/generated/java/org/apache/camel/builder/endpoint/dsl/SwiftEndpointBuilderFactory.java}}
(the header accessor names change)
** the mirrored doc copy under
{{catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/}}
h3. Tests
{{ContainerProducerTest}} uses JUnit 5 assertions throughout, so new tests stay
in that style rather than introducing AssertJ as an outlier in the module:
* {{containerCreateReadsAclFromCamelNamespacedHeaders}}
* {{containerUpdateReadsAclFromCamelNamespacedHeaders}}
* {{containerUpdateIgnoresLegacySwiftWireHeaderNames}}
* {{containerUpdateUsesCreateUpdateContainerOptionsFromBodyInsteadOfHeaders}}
(locks in the existing precedence: when the body converts to
{{CreateUpdateContainerOptions}}, the headers are not consulted at all)
* {{versionsLocationAndContainerMetadataUseCamelNamespacedHeaders}}
h3. Migration note
This changes the literal header values, so an upgrade-guide entry is required:
routes that set these headers by their string value must switch to the
{{CamelOpenstackSwift*}} names, and the Endpoint DSL accessors are renamed. The
Java constant field names are unchanged. Per the project's backport policy the
notes for the maintenance lines are added to the matching
{{camel-4x-upgrade-guide-4_22.adoc}} and {{camel-4x-upgrade-guide-4_18.adoc}} on
{{main}}, alongside the {{camel-4x-upgrade-guide-4_24.adoc}} entry.
h3. Prior decision this revisits
CAMEL-23580 excluded these four constants on purpose and recorded the reason in
the code and in the 4.21 / 4.18 / 4.14 upgrade guides. This change partly
reverses that decision, because the recorded rationale does not match what
openstack4j actually does with {{CreateUpdateContainerOptions}}. The PR
description will state this explicitly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
