Skip to content

fix: recognise the nested jars of Spring Boot when looking up the token file (#25681) (CP: 25.2) - #25696

Merged
vaadin-bot merged 1 commit into
25.2from
cherry-pick-25681-to-25.2-1789372689527
Sep 14, 2026
Merged

vaadin-bot merged 1 commit into
25.2from
cherry-pick-25681-to-25.2-1789372689527

Conversation

@vaadin-bot

Copy link
Copy Markdown
Collaborator

This PR cherry-picks changes from the original PR #25681 to branch 25.2.

Original PR description

Follow-up to #6858

behavior deviation · flow-server · applications packaged with
Spring Boot 3.2 or newer, where a dependency also contains a
flow-build-info.json

Background — the token file lookup. The build writes
flow-build-info.json into the build output folder, and the runtime
reads it from the class path at startup. A copy inside a jar is skipped,
unless the application is packaged into a jar itself, in which case its
own file is inside one too and has to be used.

Whether the application is packaged is decided by counting the archives
a resource of flow-server is inside of, and the separator counted for
that is the one Spring Boot used before 3.2. Applications packaged with
a newer Spring Boot therefore never looked packaged, and the file of a
dependency was used whenever the class loader returned it first, giving
the application the settings of the project that built the dependency.

Risks:

  • ⚠️ Behavior change: with several token files inside jars, the one of
    the application is now used instead of the first one found. The old
    order was accidental.
  • ✅ No public API changes, no security, memory, serialization,
    threading or performance impact, nothing to migrate.

Context. Spring Boot 3.2 replaced the nested jar URLs of its own
loader with the nested: protocol, which separates the jar of the
application from an archive inside it with /!, as in
nested:/app.jar/!BOOT-INF/lib/flow-server.jar!/vite.generated.ts. The
lookup only counted jar!/, so it saw one archive where there are two.

  • Counted both the jar!/ and the jar/! separator when working out
    how many archives a resource is inside of, so an application packaged
    with Spring Boot 3.2 or newer is recognised as packaged and the token
    file of the application is preferred over the one of a dependency.
  • Added a test with the nested jar URLs of Spring Boot, where the file
    of a dependency comes first on the class path.

…en file (#25681)

Follow-up to #6858

**behavior deviation** · flow-server · applications packaged with
Spring Boot 3.2 or newer, where a dependency also contains a
flow-build-info.json

**Background — the token file lookup.** The build writes
`flow-build-info.json` into the build output folder, and the runtime
reads it from the class path at startup. A copy inside a jar is skipped,
unless the application is packaged into a jar itself, in which case its
own file is inside one too and has to be used.

Whether the application is packaged is decided by counting the archives
a resource of `flow-server` is inside of, and the separator counted for
that is the one Spring Boot used before 3.2. Applications packaged with
a newer Spring Boot therefore never looked packaged, and the file of a
dependency was used whenever the class loader returned it first, giving
the application the settings of the project that built the dependency.

**Risks:**
- ⚠️ Behavior change: with several token files inside jars, the one of
  the application is now used instead of the first one found. The old
  order was accidental.
- ✅ No public API changes, no security, memory, serialization,
  threading or performance impact, nothing to migrate.

**Context.** Spring Boot 3.2 replaced the nested jar URLs of its own
loader with the `nested:` protocol, which separates the jar of the
application from an archive inside it with `/!`, as in
`nested:/app.jar/!BOOT-INF/lib/flow-server.jar!/vite.generated.ts`. The
lookup only counted `jar!/`, so it saw one archive where there are two.

- Counted both the `jar!/` and the `jar/!` separator when working out
  how many archives a resource is inside of, so an application packaged
  with Spring Boot 3.2 or newer is recognised as packaged and the token
  file of the application is preferred over the one of a dependency.
- Added a test with the nested jar URLs of Spring Boot, where the file
  of a dependency comes first on the class path.

Co-authored-by: totally-not-ai[bot] <290682512+totally-not-ai[bot]@users.noreply.github.com>
@vaadin-bot

Copy link
Copy Markdown
Collaborator Author

This PR is eligible for auto-merging policy, so it has been approved automatically. If there are pending conditions, auto merge (with 'squash' method) has been enabled for this PR [Message is sent from bot]

@vaadin-bot
vaadin-bot enabled auto-merge (squash) September 14, 2026 08:06
@github-actions

Copy link
Copy Markdown
Contributor

Test Results

 1 385 files  ±0   1 385 suites  ±0   1h 32m 6s ⏱️ - 1m 45s
10 423 tests +1  10 355 ✅ +1  68 💤 ±0  0 ❌ ±0 
10 778 runs  +1  10 709 ✅ +1  69 💤 ±0  0 ❌ ±0 

Results for commit 0394360. ± Comparison against base commit fa299a7.

@sonarqubecloud

Copy link
Copy Markdown

@vaadin-bot
vaadin-bot merged commit 5dd912b into 25.2 Sep 14, 2026
35 checks passed
@vaadin-bot
vaadin-bot deleted the cherry-pick-25681-to-25.2-1789372689527 branch September 14, 2026 08:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants