zbendhiba opened a new pull request, #28231:
URL: https://github.com/apache/camel/pull/28231
# CAMEL-25895: camel-openstack - align the remaining Swift header constants
with the Camel naming convention
## Problem
CAMEL-23580 (Camel 4.21) renamed the Exchange header constants of
`camel-openstack` to the
`CamelOpenstack*` convention used across the component catalog, but left
four constants in
`SwiftConstants` on their openstack4j values:
| Constant | Value |
|---|---|
| `SwiftConstants.CONTAINER_METADATA_PREFIX` | `X-Container-Meta-` |
| `SwiftConstants.VERSIONS_LOCATION` | `X-Versions-Location` |
| `SwiftConstants.CONTAINER_READ` | `X-Container-Read` |
| `SwiftConstants.CONTAINER_WRITE` | `X-Container-Write` |
The reason recorded in the code and in the 4.21, 4.18 and 4.14 upgrade
guides was that these names
"are part of the Swift HTTP protocol contract used by openstack4j" and that
"renaming them would
break interoperability with the Swift API".
That reason does not hold. `ContainerProducer.messageToCreateUpdateOptions`
never puts the Exchange
header name on the wire: it calls
`CreateUpdateContainerOptions.metadata(Map)`,
`.versionsLocation(String)`, `.accessRead(String)` and
`.accessWrite(String)`, and **openstack4j**
builds the `X-Container-Meta-`, `X-Versions-Location`, `X-Container-Read`
and `X-Container-Write`
names of the Swift request itself. Verified against `openstack4j-core` 3.12:
`CreateUpdateContainerOptions.create().accessRead("r").accessWrite("w").versionsLocation("l").getOptions()`
returns `{X-Container-Read=r, X-Container-Write=w, X-Versions-Location=l}`
regardless of which Camel
header key the value came from.
So the four names bought nothing, while making `openstack-swift` the only
component in its family
whose container options are driven by header keys outside the `Camel*`
namespace that
`DefaultHeaderFilterStrategy` filters by default. `camel-aws2-s3`, for
comparison, already uses
`CamelAwsS3Acl` / `CamelAwsS3CannedAcl`.
This PR partly reverses that deliberate decision from CAMEL-23580. The
decision itself was
intentional and documented; what is corrected here is its stated premise,
which is factually wrong.
Per the project's AI agent guidelines, this is called out explicitly rather
than left implicit.
## Change
`components/camel-openstack/src/main/java/.../swift/SwiftConstants.java`
| Constant | Previous value | New value |
|---|---|---|
| `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` |
- The Java field names are unchanged, so routes referencing the constants
symbolically keep
compiling and working. This matches the hard-break-with-stable-field-names
policy in
`design/headers.adoc` and what CAMEL-23580 did for the other constants.
- The now-wrong rationale comment and the unused
`org.openstack4j.model.storage.object.SwiftHeaders` import are removed.
- `ContainerProducer` needed no change: it already reads the constants,
never the literal strings.
- `design/headers.adoc` listed Swift under the "protocol and standard
headers" exemption and
pointed at these constants as the worked example. Corrected: the exemption
applies when the
header name the route sets is the name that goes on the wire, which is not
the case when a client
library builds the wire name itself.
- Upgrade note added to `camel-4x-upgrade-guide-4_24.adoc` with the value
table, the note that the
Swift request is unchanged, the migration for routes using literal header
strings, and the
renamed Endpoint DSL accessors (`xContainerRead()` ->
`openstackSwiftContainerRead()`, etc.).
- The 4.21 and 4.18 upgrade guides carried the same now-wrong rationale
paragraph, stating that
these names are part of the Swift HTTP contract and that renaming them
would break
interoperability. Both are corrected to record that openstack4j builds the
`X-Container-*` wire
names itself, with a pointer to CAMEL-25895 for the releases that carry
the rename. Left as a
pointer rather than a version so it stays correct across the maintenance
lines.
`camel-4x-upgrade-guide-4_14.adoc` is not touched: that line is EOL and
receives no fix.
- Regenerated: the component and catalog `openstack-swift.json`, the catalog
doc mirror and
`SwiftEndpointBuilderFactory`.
## Tests
`ContainerProducerTest` had no coverage of the container options path at
all. Six tests added,
in the module's existing style (JUnit 5 + Mockito via
`SwiftProducerTestSupport`; the class is
JUnit-assertion based, so no AssertJ was introduced):
- `containerCreateReadsAccessControlFromCamelNamespacedHeaders`
- `containerUpdateReadsAccessControlFromCamelNamespacedHeaders`
- `containerUpdateReadsVersionsLocationAndMetadataFromCamelNamespacedHeaders`
- `containerUpdateIgnoresThePreviousSwiftHeaderNames`
- `containerUpdatePrefersTheOptionsFromTheBodyOverTheHeaders`
- `containerOptionHeaderNamesFollowTheCamelNamingConvention`
`containerUpdateIgnoresThePreviousSwiftHeaderNames` and
`containerOptionHeaderNamesFollowTheCamelNamingConvention` fail on the
unfixed code
(`expected: <null> but was: <CreateUpdateContainerOptions@...>` and
`expected: <CamelOpenstackSwiftContainerMetadata> but was:
<X-Container-Meta->`). They are the two
that pin the values; the three `...FromCamelNamespacedHeaders` tests go
through the Java constants,
so they cover the producer path but not the rename itself.
`containerUpdatePrefersTheOptionsFromTheBodyOverTheHeaders` locks in the
existing precedence, which
the rename does not change: a `CreateUpdateContainerOptions` in the body
makes the producer skip the
headers entirely.
`mvn test -pl components/camel-openstack -Dtest=ContainerProducerTest`: 13
tests, 0 failures.
`mvn formatter:format impsort:sort -pl components/camel-openstack`: nothing
to change.
## Backports
Targets `camel-4.22.x` and `camel-4.18.x`. `SwiftConstants.java` and
`ContainerProducer.java` are
identical on all three lines, so the Java part is a straight cherry-pick;
the generated artefacts
are regenerated per branch rather than cherry-picked. Per the project's
backport upgrade-guide
policy, the matching notes go into `camel-4x-upgrade-guide-4_22.adoc` and
`camel-4x-upgrade-guide-4_18.adoc` **on `main`**. `camel-4.14.x` and
`camel-4.10.x` are EOL and get
nothing.
---
_Claude Code on behalf of zbendhiba_
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
