loustler commented on PR #11648:
URL: https://github.com/apache/seatunnel/pull/11648#issuecomment-5286892697
@DanielLeens @SEZ9 — all three points are addressed in `9ae57a540`.
**1. OssFile jar pairing (blocking).** You were right, and it was the
silent-failure case the pom comment warns about. All four `OssFile.md` variants
now list `hadoop-aliyun-3.4.3.jar`, `aliyun-sdk-oss-3.13.2.jar` and
`jdom2-2.0.6.1.jar` for the Zeta engine, with a note on why the three have to
move together — `hadoop-aliyun` 3.4.3 references
`ListObjectsV2Request`/`ListObjectsV2Result` and expects four `OSSClient`
methods to return `VoidResult`, and `aliyun-sdk-oss` 3.13.2 parses XML with
`jdom2` rather than `jdom` 1.x. Note the artifact filename changes too:
`jdom-1.1.jar` → `jdom2-2.0.6.1.jar`.
I did **not** blanket-replace the Spark/Flink example above it. There the
version has to follow the cluster's own Hadoop rather than the uber jar, so
`hadoop-aliyun-3.1.4.jar` → `aliyun-sdk-oss-3.4.1.jar` + `jdom-1.1.jar` is
still a correct answer for someone on 3.1.4. That line now carries both
pairings instead of one.
**2. `getInstance()` in the S3File option table.** Your reading of Hadoop
3.4.3 matches mine — the mechanism is real, just gated on
`isAwsV1SdkAvailable()`. Rather than change the return type, all four
`S3File.md` variants now say the `getInstance()` path is the AWS SDK v1
fallback and is only attempted when a v1 SDK jar is on the classpath, which the
shaded 3.4.3 uber jar no longer supplies.
**3. Migration note.** @SEZ9 — this one is already in the PR and I think it
was just missed: `docs/{en,zh}/introduction/concepts/incompatible-changes.md`
has a `Hadoop Shaded Uber Jar and S3A` section covering exactly the v1 → v2
provider-name migration, including the table of five `com.amazonaws.*` names
S3A remaps for you, what happens to any other v1 name, and the
`fs.s3a.aws.credentials.provider.mapping` escape hatch.
What was genuinely missing there was OSS, so I added an entry for it: the
three jars to swap in `${SEATUNNEL_HOME}/lib/`, and the fact that leaving the
old ones in place starts cleanly and only fails at runtime. That gap is
arguably how the doc bug survived this long — the S3A side had a migration
entry and the OSS side didn't.
Docs only, 10 files. Thanks for catching it — the OssFile line would have
shipped a config that builds, starts, and then fails on every listing.
--
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]
