Skip to content

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

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

vaadin-bot merged 1 commit into
25.3from
cherry-pick-25681-to-25.3-1789372669882

Conversation

@vaadin-bot

Copy link
Copy Markdown
Collaborator

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

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:09
@github-actions

Copy link
Copy Markdown
Contributor

Test Results

 1 439 files  ±0   1 523 suites  ±0   1h 29m 45s ⏱️ - 3m 55s
12 046 tests +1  11 978 ✅ +1  68 💤 ±0  0 ❌ ±0 
12 364 runs  +1  12 296 ✅ +1  68 💤 ±0  0 ❌ ±0 

Results for commit 17d668d. ± Comparison against base commit 0fb60bc.

@vaadin-bot
vaadin-bot merged commit c6a545d into 25.3 Sep 14, 2026
40 checks passed
@vaadin-bot
vaadin-bot deleted the cherry-pick-25681-to-25.3-1789372669882 branch September 14, 2026 08:14
@sonarqubecloud

Copy link
Copy Markdown

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