[
https://issues.apache.org/jira/browse/CAMEL-25895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-25895 started by Zineb Bendhiba.
----------------------------------------------
> 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
> Priority: Major
> Fix For: 4.18.6, 4.22.3, 4.24.0
>
>
> 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)
