[ISSUE apache/dubbo#13862] Migrate dubbo-samples-triple-rest-openapi-generator to Spring Boot 3.2.3

[zeng-bohan]

Migrates the last remaining Spring Boot 2 sample to Boot 3, as tracked in apache/dubbo#13862 (claim comment: apache/dubbo#13862 (comment)).

Note: this supersedes #1300, which was auto-closed when the fork head repository was briefly deleted. The changes are identical (branch re-pushed, head commit fd73f93).

Changes

• Bump spring-boot-starter-parent from 2.7.18 to 3.2.3 in dubbo-samples-triple-rest-openapi-generator, aligning the module with the dubbo-samples-triple-rest aggregate parent BOM — this was the last sample in the repository still on Spring Boot 2.x
• Replace javax.annotation-api with jakarta.annotation-api and migrate the generated sources from javax.annotation.Generated to jakarta.annotation.Generated
• Enable useJakartaEe in the pom-generator.xml openapi-generator config (7.16.0 supports it) so future regenerations stay on the jakarta namespace
• Update README system requirements: Java 8+ → Java 17+

Verification

• mvn clean package -DskipTests succeeds on JDK 17 (same command as the CI build opts, which also test against spring-boot.version:3.2.3)
• No javax imports remain under src/

Notes

• The contextLoads test requires a running Zookeeper and is skipped by CI's -DskipTests build opts, so it is not affected by this change.

[zeng-bohan]

Friendly bump after two weeks: this migrates the last remaining Spring Boot 2 sample in dubbo-samples-triple-rest to Boot 3 / JDK 17, as tracked in apache/dubbo#13862, and CI is green. It supersedes #1300 (closed in favour of this one). Would appreciate a review when someone has a moment — happy to split or adjust the scope if that makes it easier to land. Thanks!

[zeng-bohan]

Closing this for now: I've hit the per-user open pull request limit on my account and need the slot for a higher-priority change. The branch stays available on my fork, and I'm happy to reopen this once a slot frees up. Thanks!

[zeng-bohan]

The Integration Test (Java17, Job3) failure in run 34734122523 is infrastructure, not the change: the job died 48 seconds in, while composing the test environment, because Docker Hub's auth endpoint returned a 502 while pulling the mysql:5.7.40 base image:

ERROR: failed to build: failed to solve: mysql:5.7.40: failed to resolve source metadata for docker.io/library/mysql:5.7.40:
failed to authorize: failed to fetch oauth token: unexpected status from POST request to https://auth.docker.io/token: 502 Bad Gateway

Up to that point the shard was green (BUILD SUCCESS for the test runner). Two corroborating points that this is a Docker Hub-side flake rather than the migration:

• the same Java17, Job3 shard passed in the parallel run for the other Dubbo version minutes later (run 34734122556), and every other mysql-backed shard (Java8/Java11/Java21 Job3) passed here too;
• the failure happens during the docker-compose env setup, before any test of this PR's module runs.

Could someone with write access re-run the failed job? Happy to push a trivial retrigger instead if that's easier for the workflow.

[zeng-bohan]

Re-triggering CI for the Integration Test (Java17, Job3) flake — Docker Hub returned a 502 while pulling mysql:5.7.40 during compose setup in run 34734122523 (diagnosed above: the shard was green up to that point and every other mysql-backed shard passed).

While re-triggering, I also squashed the branch to a single commit: upstream master hasn't moved since this PR was opened (fcda525 is still the tip), so the new head 8fa764c is byte-identical to the old tree — fd73f93 was itself an empty re-trigger commit, so only the history got cleaner. All checks re-run on the new head.

[zeng-bohan]

Second re-trigger (Dubbo 3.3, attempt 2) also hit a Docker Hub flake, so I'm flagging it here instead of pushing another empty commit.

Run: https://github.com/apache/dubbo-samples/actions/runs/34936004364 (head 8fa764c)
Failing job: Integration Test (Java11, Job1), step Run tests

[3/22] [dubbo-samples-applevel-override:1/1] TEST FAILURE: Run tests timeout
Total: 22, Success: 7, Failures: 1, Ignored: 14

The root cause is in the container setup, before any test of this PR's module runs — pulling the zookeeper image failed:

zookeeper Error Head "https://registry-1.docker.io/v2/library/zookeeper/manifests/latest":
Get "https://auth.docker.io/token?account=githubactions&scope=repository%3Alibrary%2Fzookeeper%3Apull&service=registry.docker.io":
read tcp 10.1.0.86:52102->172.64.144.78:443: read: connection reset by peer

The dependency containers never started (docker inspect ... returned [], network ... not found), so the shard timed out waiting for them. Same class of failure as run 34734122523, where Docker Hub returned a 502 while pulling mysql:5.7.40.

Two reasons this is not the migration:

• the failing case is 4-governance/dubbo-samples-applevel-override, unrelated to this PR's module, and this shard runs JDK 11, so every case requiring JDK >= 17 (including the one this PR touches) is skipped in it;
• every other shard in the same run is green — Test Result (Java17), (Java8) and (Java21) all passed, and Test Result (Java11) only reports this shard's failure.

Could someone with write access re-run the failed job? Thanks.

[zeng-bohan]

Follow-up on the re-triggered CI, so nobody has to dig: the one red check is another environment flake, not the change.

Integration Test (Java11, Job1) (run 34936004364) failed on a container-wait timeout in an unrelated module:

wait for container is timeout: 602 s
[dubbo-samples-applevel-override] :ErrorMsg: Run tests timeout

The other 21 modules in that shard passed or were correctly version-skipped; this PR's module (dubbo-samples-triple-rest-openapi-generator) is not in Job1's shard at all.

The same commit (8fa764c) also ran in the parallel workflow run 34936004381, where all five Java11 shards — including Job1 — passed and all four JDK Test Result aggregators are green. The previously failing Integration Test (Java17, Job3) (the Docker Hub 502 leg) is green in both new runs.

Summary on this head: the migrated module is exercised and green everywhere it runs; the two historical reds are (1) a Docker Hub 502 during compose setup and (2) a 602 s container-wait timeout in dubbo-samples-applevel-override, each contradicted by an adjacent run of the identical commit.